Re: IPv6 only Plenary Makes the News
On Mar 11, 2008, at 2:31 PM, Ofer Inbar wrote: Subject: IPv6 only Plenary Makes the News Isn't that just a press release from ISOC, being distributed by wire services online? That's why they say they are making the news. Carl ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Present from the ITU
Hi Brian - Thanks for the shout out ... I blogged the whole thing at the time if anybody is interested: http://museum.media.org/eti Regards, Carl I think we should give credit to Carl Malamud and Tony Rutkowski, whe spent many months in Geneva at least ten years ago, sowing the seeds for this move by the ITU. Brian On 2006-12-25 18:41, Marshall Eubanks wrote: Since my Narten number has been rather low of late, and since this should be of wide interest and is directly relevant to the IETF's functions, and since I had not heard of it previously, I thought I would distribute this. I also thought that people would like the reasoning behind this decision. Regards ( Happy Holidays to all) Marshall Eubanks http://www.dailypayload.com/2006/1221.html ITU to Distribute Standards Free of Charge December 21, 2006 Many people in the telecommunication industry have pressed for the ITU to make its standards documents available free of charge. Well, the long wait is over. Starting January 2, 2007 the ITU will make its standards documents available to the public free of charge. The same kind of change in policy took place at ETSI several years ago. Reportedly, making its standards available for free did not have a negative impact on ETSI's bottom line. Rather, the free standards helped to drive participation in the standards-making body, thus compensating for any loss in revenue.This move came after a very long trial wherein the ITU allowed a person to register an e-mail address and download three documents free. This trial demonstrated conclusively that there was a strong desire to receive standards at no cost. Since the ITU publishes some documents jointly with ISO, special consideration will be given to those common texts, since ISO still charges for its standards and is apparently heavily dependent on the revenue from the sales of its standards. For such common texts for which ISO charges a fee, the ITU will not release documents free of charge until they are at least one year old. Documents will be made available in PDF format, downloadable directly from the ITU web site. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Something better than DNS?
Hi - I actually think the question of how a namespace is to be administered is a perfectly valid one for the IETF to consider if it impacts the performance or functionality of a protocol. We do that all the time when we give explicit instructions to the IANA in an IANA Considerations section. The IETF could also do the same in an ICANN Considerations section when it comes to the DNS. Carl Brian E Carpenter wrote, On 29/11/2006 10:43: your question is linked to whether we treat the namespace as a public good to be administered for the greater public good, or as a commodity to be treated like coffee beans. And that really isn't a question for this technological community. Depends how you look at it. Technological choices do have an impact on what the society is able to do (or not). It is up to the society to tell the engineers what it needs/wants. But I agree there are other fora for this. Patrick ___ 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: Crisis of Faith - was Re: Adjusting the Nomcom process
Hi Ted - I've tried to stay out of this, since there has been too much comment. But, I'd like to amplify your point and some others I've heard. 1. I'm offended by Todd's repeated implication that Brian has lied to the IETF. That is an ad hominen attack and goes well beyond the stated purpose of this mailing list. 2. If somebody wants to change the way the nomcom process works, they should do what we did when the system was put in place: write a document and get consensus. The IETF is all about running code, and that includes business processes. An I-D is the first step. Repeated attempts to bypass the process (e.g., by making up policy on the fly and posting it to the IETF list instead of writing an I-D) goes well beyond the stated purpose of this mailing list. 3. Repeated threats of legal actions, invocations of Jorge, and other tactics meant to bully participants do not qualify as reasoned discourse and do not contribute to the stated purpose of this mailing list. I would encourage our sergeant at arms and our leadership to take more active steps to keep discussion on the general mailing list on track. At the very least, discussants should be actively enouraged to move their discourse to more specialized mailing lists. Regards, Carl On Sun, Sep 10, 2006 at 09:44:12AM -0700, todd glassey wrote: BRIAN - you have totally missed the point - No offense meant, but your personal word nor any other IETF/IESG staff member is what is not to be relied on - whether you are telling the truth or not is irrelevant - the process has a hole in it large enough to drive a Mack truck through. Todd, it's clear you don't have any faith in anyone on the IESG (they aren't staff, by the way, they are volunteers), but at the same time, the vast majority of those who have spoken on this thread have clearly expressed that they believe that all concerned were acting in good faith, and that no harm was done. You may not believe that, but as a suggestion, your constant and strident attacks quite frankly weaken your own credibility. So if you do have a particular goal of changing how the IETF works, being a bit more thoughtful about suggesting changes will tend to probably serve your goals better than your current style of attacking people like Brian and other IESG members. Regards, - Ted ___ 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: Todd Glassey ban -- pretty please?
IMHO, fighting the messenger is not the proper solution to the problem. The messenger accused the IETF chair of lying. That is totally inappropriate behavior. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)
As for traditional mathematical notation, I think resorting to it for all but the simplest formulas, e.g. y =(m * x) + b), often does a grave disservice to all readers who are not mathematicians. RFC authors MUST NOT use calculus or matrix algebra. Addition and subtraction MAY be expressed as formulas but authors SHOULD NOT use formulations sufficiently complex to make a reader's head hurt. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
I could not agree with John more on the desirablilty of a tighter definition of PDF and the reasonableness of plates in the back. The problem with tightly defining which piece of PDF you will support is that most clients don't give the user choice on what they do. A user gets a export to PDF button, but they don't get a export to PDF/A and make sure all fonts are self-contained and don't include embedded video. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
Hi - There's been an awful lot of traffic on this subject, both this time around and in the perpetual past. My $0.02 is that we're a standards body and we shouldn't invent a new document profile/standard. That's not our business, so we should steal code. We have a home-grown effort done by a few people since 1998, which has been doing fairly well. That's a self-contained body of work, which could easily be supplemented by a working group effort to evolve the specs. If we're going to be NIH, that seems like the logical option to consider. If we don't do that, we should adopt what seems to work well for others. W3C standards look great, they've thought hard about the document format, and that's the business they're in. If we're going to last call something, I think it should be a choice from a list of existing bodies of work: w3c, xml2rfc, or any of the other document-production systems (OASIS, Docbook, ITU, OSI, or whatever you want). I'm very partial to xml2rfc, but I also see a lot of power in a joint w3c/ietf spec. That will get you tools pretty quick. If the IESG or the IAB recommended one path to take, a working group could pretty quickly do any necessary tweaks (e.g., mapping to 2629 or 2629bis). Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
It's worth distinguishing the search for alternate normative output formats from the search for a standard input format. Or are you proposing 2629bis as a standard intermediate format, which makes both camps (input and output) unhappy? I think we should pick one somewhat complete solution set and ride on top of that. For example, the w3c approach is one wagon to hitch up to. After we hitch up to a wagon, we should commission a working group to work out any additional details and the rest of us agree to live with it if they do a decent job. This is not a job for a committee-of-the-whole ... I'd be perfectly happy to let the IAB or IESG pick a religion and let a working group define the rules of procedure. And, again, piggybacking on the w3c religion seems like a really easy way out of this never-ending debate. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Copyright status of early RFCs
Hi Jorge - Take a look at Section 5.4 of RFC 1602, which redefined the IETF's IP process originally set forth in RFC 1310: 5.4. Rights and Permissions In the course of standards work, ISOC receives contributions in various forms and from many persons. To facilitate the wide dissemination of these contributions, it is necessary to establish specific understandings concerning any copyrights, patents, patent applications, or other rights in the contribution. The procedures set forth in this section apply to contributions submitted after 1 April 1994. For Internet standards documents published before this date (the RFC series has been published continuously since April 1969), information on rights and permissions must be sought directly from persons claiming rights therein. I hear you and I suppose a very, very risk averse position would hold to the letter of that document. However, John Levine put it very well when he said: Since approximately my entire income depends on copyright law (I write books), I have looked at Title 17 and its interpretation pretty closely. I have to conclude that given the facts surrounding the early RFCs: pre-1976, no copyright notice, many written on government contract, and a history of widespread copying and reuse without explicit permission, it'd be extremely hard to make a case that there were any limits on their use. I think this is what you folks in the legal profession call a business decision. There is a risk to any sort of action. As you know, being right doesn't mean you won't get sued. But, I'm with John on this one. RFCs are for all practical purposes in the public domain and it would be a very gutsy RFC author that went to court and tried to show that they had systematically defended their copyright over the last X years and were thus entitled to assert copyright this year. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
Cookies seem to be a scarce resource, so why not bring your own darn cookies to the meeting, and you wouldn't have a problem. Seriously, stop by a local grocery store, and plop down $3 and buy whatever kind of cookies make you the most happy. Aggravation avoided. That's a very community-based approach. An alternative that may better fit our institutional style is to use edible RFID tags in the cookies: http://www.gizmodo.com/archives/nec-resonantware-tomorrows-future-tomorrow-008958.php As a valuable extra, these are DRM-enabled. And, you won't have to worry about Richard Stahlman showing up at the meeting and scarfing down all the cookies. Carl P.S. My $0.02: I have full faith in the IAOC and IAD resolving this issue without our help. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proposed 2008 - 2010 IETF Meeting dates
Hi Brian - I understand the difficulty of adding too many constraints to the scheduling process, but I'd like to point out that particpants in events such as AFNOG and AfriNIC meetings don't necessarily all come from Africa. In fact, strong participation from other regions is one of the most important mechanisms for building the institutions involved. Again, I understand the constraints you face, but it is certainly worth paying attention to the fact that many of the IETF's key participants also take very seriously their responsibility to help other organizations gain critical mass. Regards, Carl Ray, I think our goal is to not lose essential participants from the IETF due to clashes. In fact that's why we want to schedule several years out, so as to make it easier for many other organizations to do their scheduling. If we do that, it's each organization's choice whether or not they avoid IETF weeks. (This week, for example, ITU-T NGN chose to schedule two major meetings in other cities.) I don't think it's discriminatory to put the NICs and NOGs that don't seem to have a large overlap with IETF participants in the second category. It's just a matter of practicality, given that optimal scheduling is a fundamentally imsoluble problem anyway. I'd be delighted to see growth in African participation in the IETF (the spreadsheet shows two people from Africa pre-registered this week). Brian Ray Plzak wrote: Why should AfriNIC be considered any less of an RIR than the other APNIC, ARIN, LACNIC, or RIPE NCC(meeting is at RIPE meeting)? Why should AFNOG be considered any less of an operator's forum than NANOG or EOF(meeting is at RIPE meeting)? We are talking about an entire continent. It seems to me in this case that the priority should be equality of treatment based on the function being performed for a region and not any other perceived reason for inequity. Or doesn't the IETF care about the Internet in the developing regions of the world? Ray -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Saturday, March 25, 2006 1:53 AM To: JORDI PALET MARTINEZ Cc: ietf@ietf.org Subject: Re: Proposed 2008 - 2010 IETF Meeting dates yOn Fri, 24 Mar 2006, JORDI PALET MARTINEZ wrote: Hi Ray, I know is difficult already to manage to avoid clashes, but I think is unfair and discriminatory to have all the RIRs and *NOGs in the MUST NOT list, but AfriNIC, AfNOG and SANOG in the other list. having attended two of three I would simply observe that the overlap between the two communites is a little lower. also. having attended every afnog meeting, it hasn't yet clashed with the ietf. You have to have some priorities. Anticipating for so many years is good enough to allow all those organizations to chat together and make sure the there is not a clash, not just in the exact dates, but allowing a few days in between (if they are hosted in different places of the world) to allow traveling among them, which has not been the case up to now all the time. Regards, Jordi De: Ray Pelletier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Fri, 24 Mar 2006 09:41:48 -0500 Para: ietf@ietf.org ietf@ietf.org Asunto: Proposed 2008 - 2010 IETF Meeting dates The IETF is proposing dates for its meetings being held 2008 through 2010. Those dates can be found at http://www.ietf.org/meetings/future_meetings0810.html The dates will be evaluated and selected to meet the IETF's standards development objectives, while avoiding conflicts with SDOs and other organizations to the extent possible. Those organizations can be found on the Clash List from the same url. Comments regarding these dates should be addressed to the IAD at [EMAIL PROTECTED] It is anticipated that an official IETF Meeting Calendar for 2008 - 2010 will be formally adopted on April 20, 2006 by the IAOC. Regards Ray Pelletier IAD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000
Re: HTTP archaeology [Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)]
... Hallam-Baker, Phillip wrote: The comments on http are rather amusing when you consider we spent the next five years trying to act on them. At the time the CERN connection to the internet was a T1. Er, the CERN connection to the NSFnet was a T1, or possibly an E1 by then. CERN had much more b/w than that to the European part of the Internet, where the majority of CERN users were (and are). Brian, who was there at the time CERN had at least 11 Mbps ... http://museum.media.org/eti/Prologue04.html Carl, who visited at the time. :) Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
But I do not believe that the concept of an RFC Editor that is independent of the IETF is a sustainable model at this time. Harald I think a degree of independence is an important part of the checks and balances that have been established and is necessary to attract a person of the stature needed to continue the role of the RFC Series as the canonical documents that define the Internet. If we consolidate too much, we cease to be an association of individuals working together to produce a rough consensus and working code and begin to resemble a corporate hierarchy. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
Harald (who has only public knowledge at this point) There isn't much secret knowledge... but as an IAOC member, I feel we've been told by the community to seek multiple proposals when possible and appropriate, and in any case to be as transparent as possible in the process. Brian Hi Brian - I agree with the first part (seek multiple proposals when possible and appropriate). However, we may disagree on the last part (transparent as possible). My formulation would be transparent without the qualifier. Transparent with a qualifier == opaque. The more opaque the leadership is, the harder it is to keep keep a system in place where anybody can participate, including participation by email (one of our hallmarks). At the beginning of this exchange, I asked a pretty simple set of questions: 1. What does the RFC-Editor think of all this? 2. Might we be looking at a situation that would result in a sole-source procurement again? Given the many years of service by the RFC-Editor, I can't evaluate the proposed actions in context, particularly if they weren't part of the so-called strawman charter drafting process. And, it would be very reassuring to hear a firm statement about the prospects for sole-source procurement or other non-competitive reassignment of core functions. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
If we consolidate too much, we cease to be an association of individuals working together to produce a rough consensus and working code and begin to resemble a corporate hierarchy. No knowledgeable individual would ever assert that the IETF is anywhere near as efficient as a corporate hierarchy. Eliot I'd say efficiency is not necessarily the metric. Contributions to science, engineering, infrastructure, and society are better metrics. In that sense, I'd say the IETF has been far more successful than any corporation, with the nice side benefit that a few corporations have benefited. But, that's not our mission. If I wanted to participate in a corporate hierachy, I'd do so in a job. Our mission is making a global Internet and, IMHO, that requires a different organizational structure. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
Hi Leslie - It would be really helpful to understand what the RFC Editor thinks of this proposed charter. Have you run it by them and what was their reaction? It would be equally helpful to understand where the IAB/IAOC is going with this ... are there plans to rebid the contract to another organization? Are there problems with the current performance of the function that you're hoping to fix by the re-chartering? Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
Carl -- did you get the other message (the one with the timeline)? Yes, I did. Not having been party to the discussions, I'm not quite sure what is going on. We did a sole source re-assignment of the IETF secretariat. As I said in my note, I'm curious about: 1. the opinion from the RFC-Editor about this, in particular the charter. 2. what the IAB/IAOC is thinking ... this could be a sole source reassignment or a simple renewal. I appreciate that a lot of thought obviously went into preparing your two notes, I'd just like to hear some of the background. Best regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FYI -- IAB statement on IANA RFI
It's been pointed out that the note to DoC was actually sent by the IAB and the IETF *Chair* not the IETF as whole. Obviously, the timescale of this RFI was too short for the IETF as a whole to debate a response. In fact, it was even too short for us to spot this nit. Or to run a spell checker? It would have been better to not answer instead of doing such a haphazard job. This was not an effective document either in terms of process or substance. Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
informal survey
Hi - I'm conducting an informal, non-scientific survey with the aim of trying to understand within an order of magnitude how much it costs folks to contribute to open source software. If any of you have 30 seconds and feel like answering 3 questions, please mail your responses back to me. Please do NOT send your responses to the entire list. Questions: 1. What country do you live in? 2. Did you contribute time to any open source development efforts in 2005? (*) 3. If the answer to 2 is yes, how much would you estimate your out-of-pocket costs were in 2005? (**) * Where contribute and open source are defined any way you feel is appropriate. ** Out-of-pocket costs are direct personal expenditures not reiumbursed by your employer. Your time is worth nothing for purposes of this calculation. Examples of costs might be web hosting, computers, or directly related travel. Thanks! Carl P.S. Privacy policy: I will not put your name on a mailing list or in any other way release your name or email address. Any results released will be aggregated over the entire survey population. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An interesting sub-note for all of you using the xml tool for drafts
Randall's method works, or you can do what the readme suggests: rfc ipr='full3978' docName='draft-mrose-writing-rfcs-01' see: http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr Regards, Carl Dear all: I recently submitted a draft to the ietf repository and got this response... Note that the front of my document had This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. as the very first paragraph.. .this was generated via the XML tool.. So, I guess the automated tool will no longer accept this statement with a reference to RFC 36668 it has to be BCP 79... and the section number. So if you are planning to do the rush to submit at the last hour... and if you are using the xml tool.. be sure to save the wording below and manually edit it into place... that is what I have been doing this week to all the drafts I have been submitting.. If you don't .. you will have a rather funny surprise aka rejected draft... and that would not be fun if your a procrastanator :-0 R The Secretariat CANNOT process your Internet-Draft submission due to following reason(s): * All Internet-Drafts must have on the first page an intellectual property rights (IPR) statement that says: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. -- Randall Stewart 803-345-0369 or 815-342-5222(cell) ___ 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: Intermediate Drafts of network layer protocols
Hi - I think a research request to study how protocols are designed and features added over time deserves a more accurate answer than an official incantation of they're gone. Try this site: http://www.watersprings.org/ You'll find all drafts and diff's between them. Regards, Carl Unfortunately, as you will see by looking at any current Internet Draft, these drafts are automatically withdrawn after 6 months (or as soon as they are updatded), so you won't find old ones on the ietf.org site. You may find them on some unofficial sites. If you look at http://www.ietf.org/html.charters/ipv6-charter.html you will find all the *current* IPv6 drafts and pointers to some of the obsolete IPv6 RFCs, as well as the current ones. Brian Syed Farooq Ahmed wrote: hello, Can i get intermediate drafts of any standard network layer protocol like IPv4 or IPv6. I am studying how protocols are designed and the features added over time etc. Normally, those drafts are removed and not found on the internet, only the last complete RFC remains. I would be thankful if any one of you can send me such drafts (documents). Regards, - - Post your free ad now! Yahoo! Canada Personals ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: a fishing expedition ...
On Tue, Mar 22, 2005 at 12:23:55PM -0800, Carl Malamud wrote: My fishing expedition is this: Have other people received a lot of these when did you first queries? If so, would you send me a private note? I promise not to use your name without your permission and will summarize my results for the list if there interest. You don't fool me, Carl. Who's trying to invalidate your patent on finding prior art to defend patents? :-) The sad thing is now I have to go search and see if somebody actually did that. There was indeed a patent granted to two lawyers on a method for writing patents, if you can believe it. For those interested in a summary ... a dozen or so people sent me notes responding that they frequently or infrequently receive such queries. Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
a fishing expedition ...
I'm conducting research for a new project, and am on a fishing expedition. From time to time, I get notes from people who are lawyers or work for lawyers asking questions in the form when did you first do foo where, in my case, foo is usually something invented by one of my distinguished colleagues which I happened to deploy. What these people are doing (though they always too coy to admit it) is trying to find prior art to defend against a patent infringement their client received. These periodic queries led me to a theory that there are a large number of patents which cover so-called inventions that were probably documented at an earlier date in an internet-draft, an ietf mailing list, an RFC, or perhaps even some form of report generated out of an IETF, Interop, INET, IEPG, NANOG, RIPE, or Apricot meeting. My fishing expedition is this: Have other people received a lot of these when did you first queries? If so, would you send me a private note? I promise not to use your name without your permission and will summarize my results for the list if there interest. Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
As for presentations, the fact that they vary in quality can't be blamed on PPT. It should be blamed on the presenters, perhaps. Brian Edward Tufte makes a very convincing case that in the case of powerpoint, the medium certainly influences the message: Summary of Tufte's views in Wired: http://www.wired.com/wired/archive/11.09/ppt2.html At a minimum, a presentation format should do no harm. Yet the PowerPoint style routinely disrupts, dominates, and trivializes content. Thus PowerPoint presentations too often resemble a school play - very loud, very slow, and very simple. Tufte's own site: http://www.edwardtufte.com/tufte/powerpoint (Worth checking out for the cartoon). Next slide please ... Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fw: Impending publication: draft-iab-dns-assumptions-02.txt
In section 3, the draft hijacks local.. Not _local. or local.arpa., but local.. hijacks is the wrong word. stuart asked long and hard for a forward-name that was nonuniversal in the way that rfc1918 addresses are, and finally he did what a lot of people do when faced with entrenched ietf religion -- he shipped his product. so where you say hijacked i say liberated. I wouldn't even use liberated ... I'd simply say implemented. .local is a good example of something that went very wrong in the IETF. The debate seemed to hinge on religious principles like universality and ignored pretty basic things like do you have code that works? and would it really hurt other things if we did this? This is all theoretical anyway: there is a huge installed base of people who use .local and the development of rendezvous-aware applications like SubEthaEdit are some of the more exciting apps I've run across lately. The fact that the mechanisms used aren't documented in the RFC series is our loss ... Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Labels in Subject Headers Considered Ineffective At Best' to Informational RFC
A very simple solution would be to write the documents in French :-) That would be illegal. ;) Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Labels in Subject Headers Considered Ineffective At Best' to Informational RFC
Merci bien pour votre suggestions ... JSPF (Je suis pas francais). :)) Regards, Carl [ Charset ISO-8859-1 unsupported, converting... ] This is an interesting proposal, however I would suggest that the grammatical mistakes relative to the french language and the cultural references be fixed. Suggestions: s/The Ambassadeur-General du France/L'Ambassadeur de France/ s/Le Academie Francais/L'Acad?mie Fran?aise/ s/Pate-du-Cochon-Degoutant-a-la-Facon-Horme/Fromage-qui-pue/ s/courriel/m?l/ (courriel was suggested by Qu?bec, not France, as far as I know) I would also suggest the author to use a standard way to represent the above non US-ASCII characters in the RFC ;-) - Alain. ___ 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: Last Call: 'Labels in Subject Headers Considered Ineffective At Best' to Informational RFC
Hi Brian - I read the first draft of this document, and wondered: Does this propose to change IETF behavior on list management, so that the name of the list (usually same as working group) is not put in the Subject: using the feature of mailman that does this? That isn't the specific purpose of this draft: it argues that labels such as ADV: are not good in the subject line. There is another draft which argues against the use of mailing list tags in the subject header and, my personal opinion, is that document should also be published as an RFC. See draft-koch-subject-tags-considered-00 for more details. snip However, until we get the latter two accomplished, I want the list manager to mark the Subject: with the name of the list. That's why I'm not specifically dealing with that issue. snip So, I ask that the author of the draft state his intentions with respect to IETF list management, and that such an intention form part of the consideration of the IETF on what to do with the draft. No, that is not the intention of this draft. I am dealing specifically with policy-mandated subject line labelling. Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Labels in Subject Headers Considered Ineffective At Best' to Informational RFC
Hi - http://www.ietf.org/ietf/1id-guidelines.txt says: Internet-Drafts must be in ASCII. No 8bit chars are currently allowed. If you need to include codepoints, a suggestion might be to use the unicode convention: U+, where X is a hexadecimal digit. So, for the quotes, if retaining the accent marks is really more important than intelligibility, Francaise would become FranU+00E7aise. I'd ask a native speaker of French which would be preferable, but I strongly suspect that they'd find the ASCII mis-spelling less distasteful. http://trusted.resource.org/no-solicit/ has the xml source and the html rendition. In the xml, I use the proper utf-8, which shows up in full glory in the html. For the ascii version, I concur with Randy's opinion that it makes the most sense to sacrifice the accents, a service that xml2rfc does very effectively. My apologies to French speakers (and, of course, my repeated apologies to any citizens of Freedonia as well). Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Controlled vs Managed (Re: ASCII diff of ISOC-proposed changes to BCP)
Hi Leslie - For myself, I find the arguments on both sides of controlled and managed to be compelling -- perhaps because I am not a lawyer. Finding both sides compelling makes you very qualified to be a lawyer. ;) snip So, if the token really doesn't mean anything (per Jorge) because the import is in the text of the document, perhaps the right answer is to just *drop* that clause. That makes sense. Regarads, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for ISOC pre-indication of consent: BCP-06
Hi - If anybody has problem reading .doc files, here is a version in pdf: http://public.resource.org/adminrest/IETF-IASA-BCP-v6.pdf Regards, Carl Per Harald's request, ISOC's legal counsel reviewed the latest version of the IASA BCP and suggested a number of minor changes. These changes are not intended to be substantive, but rather to accommodate legalese or to improve clarity (in a legal sense). The changes have been reviewed by and are supported by the ISOC Board and they have also been reviewed with Harald. To help with context and therefore speed review, the changes are in a word document and the comments are marked using the track changes functionality. The document can be found at: http://www.isoc.org/standards/IETF-IASA-BCP-v6.doc Regards, Lynn ___ 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: IAOC Responsibilities
Hi Bob - Since I examined some of the issues you raise in some depth as part of my consulting engagement, I thought I could provide some useful background on some of the points you raise. For those who are interested, I looked at these issues in two reports: http://www.alvestrand.no/ietf/adminrest/docs/draft-malamud-interim-data-flows-00.html http://public.resource.org/adminrest/draft-malamud-consultant-report-01.html (both are in the i-d directory as well). snip Although CNRI ran all aspects of the IETF Secretariat prior to 1998, and provided technical leadership as well, since then the provision of services has been carried out by Foretec Seminars, Inc. under contract to CNRI. CNRI maintains the oversight of the activity, which is the province of many of the topics discussed in connection with the IASA activity and the IAOC in particular. One of the aspects of this oversight activity is quality control of not only the services provided in support of the IETF, but quality control of various aspects of the associated intellectual property. My view is that the process undertaken on the public list has been very useful in describing what the IETF would like to see happen in the future. Although CNRI has not participated actively in the recent public discussions, CNRI has committed publicly to working with the IETF in its restructuring efforts going forward.br Your CNRI 2002 tax returns showed that CNRI owns 96% of Foretec Seminars, so I have a very tough time making a distinction between the two. The Foretec board of directors serves at the pleasure of the CNRI board. nbsp;br If, in due course, CNRI were to come to an accommodation with the IETF leadership as to how best to transition the current situation to a structure more along the lines indicated in the discussions to date, there are still many important issues that would have to be resolved. The issue of managing intellectual property is high up on that list. Whether or not the provision of services is provided under contract to CNRI or not in the future, to a large extent, the matter of managing intellectual property can be separated from the equation.br There is absolutely no paper trail of any sort showing CNRI as managing intellectual property. I see no consultations with IETF leadership and, indeed as shown below, I don't feel that there has been any active management on CNRI's part. Indeed, on the question of preservation of intellectual property through proper archiving, I've only found gross neglect. nbsp;br Among the issues to consider is (if CNRI does not provide the function) who will be responsible for administration and quality control over the use of trademarks, and how will that responsibility be carried out; and who will be responsible for managing proprietary materials developed for the IETF and how can they best be transferred to other parties in the event a transition is required. br These are two different issues. 1. Trademark. There is only one trademark that I have found, a US registration for the word mark IETF Secretariat. In particular, the term IETF has not been registered. I dealt with that issue in my second report and it appears that the registration by CNRI was a defensive measure to protect the community and was done as part of the work for hire arrangement in which the community engaged CNRI based on a verbal agreement. That's the nicest way I can describe it. In any case, this is not intellectual property to be bartered and my advice was that if CNRI feels this *is* property, the entity which provides support services should simply call itself something else. 2. who will be responsible for managing proprietary materials . The answer to that is quite clear: the IAOC will handle these matters going forward as part of ISOC. The answer is also quite clear that the community would prefer that there not be proprietary materials. Related to that, I'd like to reiterate my conclusion about any intellectual property related to the IETF: after extensive discussions and research, I can *only* conclude that neither CNRI nor Foretec hold any intellectual property interests in materials pertaining to or developed for the IETF. snip While CNRI currently intends to hold the IETF-related assets developed over many years, we are willing to consider placing these assets in a trust arrangement for use by the IETF in the future. The proposed IAOC could be tasked with additional responsibilities in this regard, but this would have to be worked out in some detail.nbsp; In general, such responsibilities should be added to the list in the draft IASA (proposed BCP 04), section 3.2 as follows:br snip There are significant provisions in the current draft and, as far as I can tell, a strong community consensus. It isn't fair to other members of the community to treat the current document as a jumping off point for protracted additional negotiations. I'm a bit bothered by the term
Re: Resolution? #787 terminology - in particular ISOC Standards Pillar
Bert - I assume from the long to and cc list you are looking for me too affirmations. I'm 100% fine with what you have and, if any of the other folks think you're only 95% and propose tweaks, let me say in advance I'm fine with that as well. Regards, Carl So... not 100% sure I captured the result ciorrectly. This is what we have in rev 04: section title=Divisional Accounting anchor=divisional-accounting t Funds managed by IASA shall be accounted for in a separate set of accounts. Separate financial reports, including a balance sheet and a profit and loss statement for IASA alone, shall be produced as directed by IAOC. /t t IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. /t /section This is what I have in my edit buffer for revision 05 section title=Cost Center Accounting anchor=cc-accounting t As discussed with ISOC, funds managed by IASA shall be accounted for in a separate set of accounts within the Cost Center IASA. A periodic summary of the IASA accounts shall be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IASA cost center. /t t IAOC and ISOC shall agree upon and publish procedures for reporting and auditing of these accounts. /t t Note that the ISOC in consultation with IAOC can determine to structure the IASA accounting differently in the future within the constraints outlined in xref target=isoc-responsibilities/. /t /section Is that acceptable to everyone? I have left the change to General Ledger Accounts out for the time being, because I am not sure we have consensus on that yet (even though ISOC prefers that terminology). Bert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Margaret Wasserman Sent: Wednesday, January 26, 2005 01:47 To: Lynn St.Amour; Carl Malamud; Tom Petch Cc: Harald Tveit Alvestrand; Lynn DuVal; ietf@ietf.org Subject: Re: Resolution? #787 terminology - in particular ISOC Standards Pillar Lynn's suggested text is fine with me. Margaret At 4:53 PM -0500 1/25/05, Lynn St.Amour wrote: Margaret, I agree with your point below but I do feel it is helpful to state what ISOC's intended implementation is: a Cost Center within ISOC. This should not override the section (principle) you quote below. Perhaps we can add language at the beginning of this section to clarify all this (or move the paragraph you quote from section 7 to this section). We might also add some of the other language proposed (see immed. below) so that the overall intent is clear rather than focusing on the less important detail. ...periodic summary of the IASA accounts in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of that cost center. Regards, Lynn At 9:20 AM -0500 1/21/05, Margaret Wasserman wrote: snip There is a section of the BCP that says: Within the constraints outlined above, all other details of how to structure this activity within ISOC (whether as a cost center, a department, or a formal subsidiary) shall be determined by ISOC in consultation with the IAOC. It seems inconsistent with this section to mandate elsewhere that the IASA will be organized as a cost center, that we will use cost center accounting, that the financial reports will include a PL for the cost center, that we will publish the general ledger accounts, etc. These are details that, IMO, the IAOC and ISOC should work out (and change as needed to meet the needs of IASA and the IETF community) between themselves. ___ 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 ___ 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: Resolution? #787 terminology - in particular ISOC Standards Pillar
Hi Margaret - Maybe we agree, but I'm not sure. I used the following phrase: periodic summary of the IASA accounts in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of that cost center. So, I agree with you that this doesn't have to say of that cost center and could easily say the IASA. But, when you say in the form of a PL statement, I get a little scared ... as you know from your periodic reviews of the ISOC overall finances, an income statement without a balance sheet doesn't make a lot of sense. While keeping implementation details out of the BCP is a good thing, I do think it is appropriate to get the general principle across: full visibility and transparency of the IASA activity through the use of regular reporting using standard financial statements that show the IETF community the income, expenses, assets, and liabilities of this particular activity. The general principle is that, because this is a community activity, we're all agreeing that more visibility than usual is appropriate here. That seems like a reasonable request/requirement, particularly given the past history of minimal reporting by the secretariat. Not your fault, I know, but this is a sensitive issue given the history and thus requires a little extra attention. Regards, Carl I generally agree with Tom and Carl. The community needs visibility in to the IASA finances, sufficient to ensure that the IETF's money is spent on IETF-related activities with a reasonable level of prudence. I don't think that our BCP needs to specify a reporting methodology that the IAD/IAOC should use to provide that visibility... Today, we are looking at organizing the IASA as a cost center within ISOC, and it seems likely that the visibility that the IETF needs can be provided in the form of a PL statement for the costs center and a summary of its general ledger accounts. That's fine, but do we need to say it here? There is a section of the BCP that says: Within the constraints outlined above, all other details of how to structure this activity within ISOC (whether as a cost center, a department, or a formal subsidiary) shall be determined by ISOC in consultation with the IAOC. It seems inconsistent with this section to mandate elsewhere that the IASA will be organized as a cost center, that we will use cost center accounting, that the financial reports will include a PL for the cost center, that we will publish the general ledger accounts, etc. These are details that, IMO, the IAOC and ISOC should work out (and change as needed to meet the needs of IASA and the IETF community) between themselves. Margaret At 11:43 AM -0800 1/20/05, Carl Malamud wrote: Hi - I agree with Tom that this is kind of confused, and I think there is some potential fast and loose use of the language of accountancy. :)) I think the vague term accounts is just fine for the purpose we are engaged in. I think all we're trying to say is that the ietf community would like to see a periodic summary of the IASA accounts in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of that cost center. I don't think we need to get into general ledgers and all that other technical accounting talk. Regards, Carl Inline, Tom Petch - Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org Sent: Wednesday, January 19, 2005 3:24 PM Subject: Resolution? #787 terminology - in particular ISOC Standards Pillar In #787, Margaret raised a couple of terminology questions related to the terms: - IASA Accounts - IETF accounts - ISOC Standards pillar In discussion, it seems clear that IETF accounts is a mistake, and should be changed to IASA accounts wherever it occurs. IASA accounts should probably be changed to IASA general ledger accounts - to have a recognizable term from bookkeeping instead of the rather vague term accounts. general ledger is indeed a recognizable term from bookkeeping but it is not the one I would want to see. Accountancy (as taught to me) divides up the ledger into accounts, and yes, acccounts is also a recognizable term. The ledger is typically divided up into (traditionally physical separate books) - purchases/creditors ledger - sales/debtors ledger - general/impersonal ledger - private ledger so seeing only the general ledger gives me an incomplete, perhaps misleading view of the financial state of an organisation. In fact, I would want to see the private ledger first since it contains profit and loss, trading, drawings etc. More generally, I would want to see the IASA accounts (an accountancy technical term) in the ledger (another accountancy technical term). Or do these terms
Re: Resolution? #787 terminology - in particular ISOC StandardsPillar
Hi Tom - Ah ships in the night; yes, Carl, I think this is the best wording so far. Two queries in my mind. Looking at the ISOC Report 2003, I notice it uses revenue rather than income that you use; is there any hidden meaning in that? eg because it is incorporated as a nonprofit organization? Revenue and income are equivalent. In the non-profit world, we prefer revenue to income and excess of revenues over expense to the word profit. And reading between the lines, perhaps I should be less trusting of ISOC so is it sufficient to say periodic summary? Is there any implication elsewhere of how often periodic is? I expect accounts at least every 12 months for any organisation, with them being more frequent for larger organisations, even every three months for some. I really wouldn't bother specifying that. My personal view? Quarterly is always nice. But, I think that's something for the iaoc/isoc/etc... to work out ... they can figure out if their specific actions meet the general principle easily enough. And, I wasn't being at all distrustful here of ISOC ... I was just trying to express the general principle in traditional language. (Same with your cash flow analysis ... while I always prepare those for my organizations, it would be unusual require such a level of analysis for external consumption, and it probably wouldn't give you a tremendous amount of insight into the functioning of a cost center as that part of the operation is backed by the overall organization. That's why I just listed the usual 4 of revenue/income, expenses, assets, and liabilities.) Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Resolution? #787 terminology - in particular ISOC Standards Pillar
Hi - I agree with Tom that this is kind of confused, and I think there is some potential fast and loose use of the language of accountancy. :)) I think the vague term accounts is just fine for the purpose we are engaged in. I think all we're trying to say is that the ietf community would like to see a periodic summary of the IASA accounts in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of that cost center. I don't think we need to get into general ledgers and all that other technical accounting talk. Regards, Carl Inline, Tom Petch - Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org Sent: Wednesday, January 19, 2005 3:24 PM Subject: Resolution? #787 terminology - in particular ISOC Standards Pillar In #787, Margaret raised a couple of terminology questions related to the terms: - IASA Accounts - IETF accounts - ISOC Standards pillar In discussion, it seems clear that IETF accounts is a mistake, and should be changed to IASA accounts wherever it occurs. IASA accounts should probably be changed to IASA general ledger accounts - to have a recognizable term from bookkeeping instead of the rather vague term accounts. general ledger is indeed a recognizable term from bookkeeping but it is not the one I would want to see. Accountancy (as taught to me) divides up the ledger into accounts, and yes, acccounts is also a recognizable term. The ledger is typically divided up into (traditionally physical separate books) - purchases/creditors ledger - sales/debtors ledger - general/impersonal ledger - private ledger so seeing only the general ledger gives me an incomplete, perhaps misleading view of the financial state of an organisation. In fact, I would want to see the private ledger first since it contains profit and loss, trading, drawings etc. More generally, I would want to see the IASA accounts (an accountancy technical term) in the ledger (another accountancy technical term). Or do these terms change meaning as they go west across the Atlantic? snip ___ 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: Firing the IAOC (Re: Consensus search: #725 3.4b Appealing decisions)
Hi - Just so we're clear, I think a mass execution procedure is a bad idea. Serial executions are much better: these people got seated one by one, and if you don't like them, each one should get their own trial and sentence. Changing 3777 to allow group trials seems like a task well beyond the current exercise, which should be focused on how to get the IAOC on board and functioning. I fully expect that our founding fodders on the IAOC will do a great job and that we should focus on building this particular bridge instead of establishing procedures for burning it down. Regards, Carl Carl Malamud wrote: The one thing that I agree sticks out is that the language of 3777 talks about firing *one* person - in the case where the group is dysfunctional, it may be better to take the group out, as you say. I think if there is enough momentum to engage in these procedures, it won't be hard to take them out one by one. I think that's better than firing an entire group. Individual accountability is a good thing. If we do the take out the whole group procedure, might as well have a similar procedure for the IESG and the IAB. There aren't so many IAOC members. The group of 20 petitioners can easily send in simultaneous recall petitions for all of them. For that matter, the same is true of IAB and IESG recalls - a little cut and paste goes a long way. Actually, I think Carl is correct - a very slight tweak to the wording of 3777 would allow it to apply to one or more people. I don't presume that firing the whole committee is more likely than firing one individual who is causing problems. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Firing the IAOC (Re: Consensus search: #725 3.4b Appealing decisions)
The one thing that I agree sticks out is that the language of 3777 talks about firing *one* person - in the case where the group is dysfunctional, it may be better to take the group out, as you say. I think if there is enough momentum to engage in these procedures, it won't be hard to take them out one by one. I think that's better than firing an entire group. Individual accountability is a good thing. If we do the take out the whole group procedure, might as well have a similar procedure for the IESG and the IAB. Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call Comments on draft-iasa-bcp-04.txt
I agree with Scott on this one. In-kind contributions are great if they have a real purpose, which in this case it means the folks responsible for deploying the contribution have to agree it is worth the trouble. Another example is somebody accepting a bunch of equipment for use in the next IETF meeting when the NOC doesn't necessarily need or want that item. Regards, Carl Margaret asks ISSUE #5: 6. There shall be a detailed public accounting to separately identify all funds available to and all expenditures relating to the IETF and to the IASA, including any donations, of funds or in-kind, received by ISOC for IETF-related activities. In-kind donations shall only be accepted at the direction of the IAD and IAOC. What is the purpose of the last line? Is there some fear that someone would accept inapproprite in-kind donations? What happens if they do? I intended that last line to make it clear that its the IETF (though the IAD and IAOC) that decides if an in-kind donations is actually something that the IETF wants and is comfortable with any conditions - for example someone might be concerned if the ISOC accepted an offer from Bill' bait sushi shop to sponsor lunches at IETF with the minor requirement that an add for BBSS be appened to all RFCs Scott ___ 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: Consensus? #733 Outsourcing principle
John makes a very good point. I prefer to think of these types of documents as a Request for Information (RFI), which is a common contracting mechanism. It allows vendors to make general presentations about their capabilities, and that allows the host institution to put together a short list of potential contractors with whom they can engage in serious discussions. Those discussions then result in negotiations and, hopefully, the selection of a vendor and the execution of a contract. The RFI ensures that everybody knows this opportunity is there. That's different than a binding RFP where criteria for selection (e.g., 10 points for lowest cost, 10 points for technical aptitude) are published in advance and then applied based on the proposals submitted. Regards, Carl --On Thursday, 13 January, 2005 17:42 +0100 Wijnen, Bert (Bert) [EMAIL PROTECTED] wrote: We definitely do want to discourage egregious bloat of direct staff posts, but we also want to discourage egregious bloat at the contractors we outsource to. I'm not sure why people think there is more risk of one than the other. With the outsourcing model, my underastanding is that we want to do it via an RFP process, and so that would help (I hope) reduce bloat. Bert, It is not easy to write really good RFPs. Indeed, it is generally quite hard. Perhaps more important in this context, normal RFPs are good at explaining to would-be bidders or contractors what will be expected, but don't necessarily provide good explanations of why we would want it done or how we justify it. If poor RFPs go out, or poor contracts are written, we end up with contractor-management or renegotiation problems that are typically more difficult than employee job descriptions and contracts, since the latter usually include such additional tasks as required clauses. No sensible external contractor agrees to such a clause without the ability to renegotiate the agreement, demand additional fees, etc. A comitment to an RFP process does ensure that the IASA puts resources into RFP-writing, RFP-evaluating, and similar activities that may be useful but may not, for a given situation be, to use EKR's term, efficient. If we get multiple bidders on the same well-written RFP, we can perhaps expect them to compete to produce the lowest price or fewest staff needed to meet the RFP/contract provisions. However, the Internet community had not had wonderful experiences with low bid contracting, especially if the RFPs are not exceptionally well written: getting the job done well is often more important than getting the job done at the minimal level needed to conform to an RFP or contract. So, with or without an RFP process, we are back to needing to trust the judgment and skills of the IAD and IAOC, with the remedy of firing the latter if they screw up often enough. An RFP process followed by an outsourcing contract does require that expectations be written down. That is a good thing, but there might be other, more efficient, ways to accomplish it in some cases. And, again, it doesn't help much to assure us that sensible decisions are being made about bloat-minimization: that is a program analysis and evaluation function, not an RFP one. 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: #720 and #725 - Appeals and IAD autonomy
Hi Spencer - [ Charset ISO-8859-1 unsupported, converting... ] Hi John - Your note seems like an outlier. In particular, it takes a really *strong* stance on protecting people from each other because people *will* act badly. For example, the way I read your note, the IESG will micromanage and the IASA/IAD will order bagels flown in daily from New York. Appeals will be a daily happening and people will hire lawyers instead of working it out. John's note took a stronger stand than I would have taken, but I happen to agree with most of his points - especially that IASA/IAD effectiveness should be evaluated in large slices. Maybe annually, certainly not decision-by-decision. Periodic reviews are good ... Marshall Rose once suggested a 3-year sunset clause. In any case, you know you can do that review without having that in the BCP? (As could ISOC.) That's a unilateral action and the BCP is supposed to cover a mutual agreement. In my second marriage, I have learned that in a partnership vital to both parties, I don't get to pick the parts I like and demand that the other parts change. It's a package deal. If the package works, great, but trying to turn a package that doesn't work into one that does, part by part, just isn't worth the aggravation and agony. Well, mumble, since we're going down that metaphorical rat hole ... You're right ... you can't make people change part by part. But, I can't somehow imagine a marriage between people preceeded with a 6-month pre-nuptial negotiation period. Perhaps in New York City, but certainly not on the west coast where I live. It seems to me that the IETF has been shacking up with ISOC for 10 years, has gone through an intensive courtship period with lots of dating rules, and that if this marriage is going to work less time should be spent planning the divorce and a bit more time on planning some romantic honeymoon activities like forming committees, doing budgets, and evaluating IAD applicants. I just don't see any marginal gain in further tweaking of the vows and even if you get your prospective bride to utter specific words, the lawyer/priest won't be around after the ceremony and you're going to have to work together. Isn't it time to cut that cake? Best regards and happy holidays Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: #720 and #725 - Appeals and IAD autonomy
Hi John - Your note seems like an outlier. In particular, it takes a really *strong* stance on protecting people from each other because people *will* act badly. For example, the way I read your note, the IESG will micromanage and the IASA/IAD will order bagels flown in daily from New York. Appeals will be a daily happening and people will hire lawyers instead of working it out. I think you're trying to solve many corner cases. I don't think we need to solve them right now. As Dave Farber would say, maybe we should burn those bagels when we get to them? Seriously: this BCP seems, imo, pretty much cooked. There may be flaws and holes that people forgot, but this would be alot easier to nail down if we had some operational experience in the new framework and then solve problems that are real. There are lots of checks in balances in place, there are going to be lots of new people who have to get up to speed, and the community is watching. I know you don't want to revise the BCP every 10 minutes for the next 10 years, but if we had to ammend it once or even twice, this would not be a big tragedy. My personal advice: let's stop negotiating, call this BCP cooked, and move on to other fires. Carl (speaking as a private citizen again ... my contract with ISOC has run it's course) --On Thursday, 23 December, 2004 10:22 +0100 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: John, ... I like all of those properties, and it should be a small twist of language (starting from the text in the draft, not the most recent suggestion) to make it come out that way. But I'm not sure I'm reading your words correctly, so better double-check A fascinating question, actually. I think you are reading my words correctly and that, by happy coincidence, the words that are now in the draft are fairly easily adapted. But the principles are more important than the words, and I think this is a profound change in principles. It is, I think, a significant change to say if you expect the IAOC model to succeed, * the IETF has got to keep its hands off the day-to-day decisions, even when they seem wrong * the IESG and IAB need to be prohibited structurally from micromanaging, or managing at all, beyond the degree that the IAOC wants to permit. They supply input, they make requests, but decisions rest on the IAOC side of the wall and stay there, with the only _real_ recourse being to fire the IAOC and then to figure out a way to implement those principles. Actually, I think we have agreement on those principles, and have mostly been struggling with how to express them. Appeals procedures (under whatever name) are procedures that should exist so that if someone thinks something's gone really wrong, it's possible to get it noticed and talked about - and, if it's necessary, corrected. Trying to manage anything by routine appeals is totally broken. Well, perhaps we are close enough that it doesn't make sense to have further discussion without text, and text in context, but... I think the something's gone really wrong and ...corrected part of the above _might_ miss the point I'm trying to make. (1) If you have an appeal procedure, any appeal procedure at all, then it is up to the judgment of the individual members of the community whether a decision is really wrong. I don't need to worry about denial of service attacks here, just about people acting in good faith and with the best of intentions. Remember we have had debates on the IETF list about the variety of pastries to be available during meeting coffee breaks as well as the theory for selecting meeting sites. I may be too concerned about this, but I think those debates could easily have led to appeals about meeting locations when people concluded that the decisions being made were against the expressed consensus desires of the community (or against plain good sense). Such appeals have been prevented by the assumption that the IETF membership has no ultimate control over _individual_ secretariat or Chair meeting siting decisions and that contracts are already signed by the time meeting sites are announced. That has protected us from procedural entanglements that could easily make meeting scheduling impossible. But, with the presumed requirements on the admin structure for openness, that particular protection disappears. (2) If there is an mechanism, any mechanism at all, for the IESG and IAB to second-guess administrative entity decisions, I think it can be guaranteed, given the sorts of personalities we put on those bodies, that the mechanism will sooner or later be used and that, once used, there will be a tendency for
Re: #720 and #725 - Appeals and IAD autonomy
Hi John - (i) the IESG, or the IESG's leadership, is likely to micromanage because it has tended to micromanage, or try to do so, many of the things it has touched in the last several years -- the secretariat, the content of various documents down to the editorial level, the RFC Editor, and so on (some of that has gotten better in recent months or years, but that isn't the point). Even you have made the claim that they (for some instance of they) have tried to micromanage you in terms of the contents of your various reports and recommendations. And the discussion of why the IETF and IAB Chairs had to be on the IAOC had, to me, a strong ring of so we can make sure that administrative entity does exactly what we want, which is close to an operational definition of intended micromanagement. So that one isn't a corner case, it is a simple extrapolation from behavior that has been observed in the community (and commented upon in the Problem Statement work, which makes it feel like I'm not alone in those impressions). Hmmm I don't see how worrying this particular BCP to death is going to change any of that. You're talking some pretty fundmamental doom-and-gloom stuff. If things are that broken, could any BCP fix them? (ii) If I'm worried about bagels (I'm really not), I'm not worried about the IAD/IASA making that decision: I expect those people to be firmly in contact with fiscal realities and priorities. If they are not, we will have far worse problems than the bagel supply. But I'm concerned about even the possibility of bagels-by-appeal, or bagels-by-IESG/IAB-overriding IAD decisions, even while realizing that particular example is (deliberately) unlikely. And, as I said, the issue I'm raising is a key management and management-relationships principle. Whether one agrees with it or not, characterizing it as a corner case seems to me like a stretch. Hmmm again ... maybe it is just the holiday spirit, or the six months of intensive community work that has gone into the document, but it just seems to me that bagels-by-appeal, or any of the other bagel-related scenarios, are corner cases. snip for brevity No. But I've heard that the draft IAD job description was floated by a couple of HR/ search experts (I believe at least one of those reports has not been forwarded to the transition team because there was no indication that the advice was wanted) and that the comments involved phrases like incompetent description and no one sane would take a job defined that way. These are not small issues: they go to the very core of the likely ability of the IAD and IAOC to function. To paraphrase an out-of-context quote from a different discussion, I don't want to see Harald become the next-to-last Chair of the IETF because of this process. Put differently, I'd like to be sure that principles are well enough articulated, and details left to where they can be worked out, that we get a chance to revise the BCP without completely killing the IETF in the process. Well, I wrote portions of that description, so I definitely resemble that remark. ;) I think you're overblowing this IAD position by asking for things like executive searches. Feel free to furnish new text to the committee ... As to the end of the IETF, mumble. That seems a bit much. My personal advice: let's stop negotiating, call this BCP cooked, and move on to other fires. And my personal advice is to make sure that we get the principles right and that we do so, as needed, based on competent review and advice. I also recommend that we look at past behaviors and assume that they extrapolate cleanly into future behaviors unless reasons or conditions can be identified that make such extrapolation inappropriate. I further recommend that it is far more useful to look at those extrapolations and what they mean about both principles and implementation than it is to spend a lot of energy on scenarios that are really unlikely, such as how things would be handled, in detail, if IETF income from meeting fees significantly exceeded all expenses in a given year. You may have noted that I've said virtually nothing, on or off-list, about editorial matters that don't impact principles except sometimes to suggest that excess detail be removed. That is not an accident. It is consistent, I think, with your desire to get this cooked and out but without pushing important issues under the proverbial rug in the process. YMMD, of course, and likely does. It does. I've seen a remarkable degree of consensus, a few tweaks on a few things, but no huge disagreement that the principles are wrong. It may not be a great document, the framework may not be ideal, but I think y'all should move on and get back to some real work. :) Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
Well, I'd like to suggest that we should decide not to decide at this time. It is a low-level issue compared to getting the BCP to a point of consensus and keeping to the schedule for creating the IASA. As a survivor of many ISOC Board discussions on such issues, I can tell you we aren't going to converge any time soon - so could we agree to put it aside? That will mean adding a few weasel words in the draft, but that's easy if we agree to disagree, e.g.: Accounting mechanisms for small designated donations will be decided in the light of experience instead of the last sentence of 5.3 para 2. Hi Brian - I think you should do what it takes to get a consensus on the doc. :) If that means dropping the language altogether and that makes people happy, that's the answer. If it means leaving it in, but putting in a clause that makes you happy, that works as well. May I make a suggestion? Run the small donations program for 1 year as an experiment (e.g., don't enshrine it as a dedicated principle), charge any costs for administering that program back to the IASA accounts, and then evaluate at the end of the year if it is a worthwhile thing. In terms of BCP language? Something like: The IASA and ISOC shall investigate concrete mechanisms that will allow small contributions designated for use in the IASA and shall report back periodically to the community on such matters. (Or, any language that makes you, Lynn, Scott, Bert, Leslie, and the others who spoke up on this issue happy. IMHO, this shouldn't be a gating issue and folks seem pretty close to agreement. It seems like people are simply arguing over the level at which this mechanism might kick in ... US$1 is clearly too small, US$1m is clearly large enough.) A suggestion? Maybe Leslie and Lynn could talk and propose something in this area? I'm sure I would immediately agree to anything they proposed. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
Hi Leslie - There's something I'm not quite understanding, and I was wondering if others might share my confusion. I can think of two reasons why taking small targeted donations is bad: 1. It's a pain to administer and account for. 2. It screws up the overall marketing plan in some way (e.g., should a $1 donor get their name on the web page, should bigger sponsors be part of some bundling strategy, etc...). I could understand 1. being a problem if people could designate specifically what they want (e.g., support the newtrk working group). But, if the only designation available is support of the IETF, it is a pretty simple accounting transaction to book all receipts with that designation as Discretionary Funds Used for IASA. It becomes a line-item on the income statement and balance sheet, and becomes one line in the annual tax return under restricted contributions received. If the number becomes high, there are some implications for the public support test the IRS uses, but that doesn't seem to be an issue for the forseeable future. My confusion is whether people think that designating means the donor writes the conditions or whether it simply means support of IASA. If it is the latter, it really isn't that tough to administer. If it is the former, I'd be kicking and screaming if I were Lynn. :)) As to the second reason why one might not do this, my own personal opinion is that if people want to make any size contribution to the IETF and there are no strings attached, we shouldn't be so proud as to say no. Regards, Carl 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
Re: Assuring ISOC commitment to AdminRest
Pete - This debate between John and Pete seems to be at such an abstract meta level to me, that I have difficulty to try and see what it means for the IAS BCP doc that I thinkwe are trying to get consensus on. As I said, it could be just me, but I seem unable to map it to any issue(s) with the curremt text in rev 02 of the doc. Ignoring John's caricature of my position: I think I am suggesting an addition to the current BCP which more or less says: This BCP will take effect upon adoption of the BCP by the IESG and the concurrent insert thing that ISOC does which codifies in some interesting way the adoption of the relationship by ISOC This sounds pretty concrete ... any agreement has to be ratified by both parties and the current draft doesn't say how that will happen by ISOC. I also suggested to insert for the part in : adoption of an ISOC by-law signifying the adoption of the principles laid out in this BCP. I'm fine with your or any other ==yes. Regards,, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
On 2004/12/07, Bob Kahn wrote: I think it fair to state in the document what the IETF thinks appropriate for it to manage its own affairs going forward, but one of the matters we will have to work out is the fact that there is considerable IP generated over the past almost twenty years. At present, CNRI owns most of this IP, but the US Government may have certain continuing rights in the data as well. Dear Bob - I think I'd like to address this issue since you've brought it up. In case you haven't had a chance to read my interim report, you will find some more details on this subject: http://public.resource.org/adminrest/interim_report/ I was very careful in that report to give a variety of options that the community might wish to pursue. However, there was one very concrete recommendation: In my opinion, Foretec should make a copy of the source code and regular dumps or phpmyadmin access to the IETF's datatracker available to the IETF community as soon as possible. Note the word should which has very precise meaning in the IETF. As you know, I've spent a great deal of time looking into how the IETF operates. As part of my due diligence, I read very carefully the agreements that CNRI had with the US government, pulled the CNRI tax returns, and looked at the financials you've furnished to the IETF leadership. I went through a similar process with other organizations involved, so I think I've got a pretty good feel for how the IETF has been financed and operated over the past 18+ years. My conclusion is pretty simple: CNRI and Foretec do *NOT* have any ownership interest in the IETF. You own your physical assets such as computers, but you do not own any intellectual property related to the IETF. None. In the particular case of the datatracker, that has been developed during a period where IETF meeting attendees have been paying in around $2 million per year to CNRI. Those meeting fees paid for the meeting and the operation of the IETF secretariat. We paid for that datatracker and Al Vezza's repeated refusal to provide a dump of the database to the IETF because of proprietary concerns is just plain wrong. When I hear ownership interests get tangled up in the discussion of how an international public community like the IETF will move forward, I've got a problem. CNRI has operated the secretariat for 18 years, and everybody has repeatedly said how grateful the community is for that service. But, it is just that: a service. Any assets created were public assets and are held in trust for the community. For example, CNRI was kind enough to register ietf.org for the community. But, you don't own that domain name. You registered it on behalf of the community. Had you asserted ownership on that name, I'm *sure* there would have been extended discussion of the topic on the IETF list. The same goes for the trademark registration you made for the term IETF Secretariat: that is simply a prudent defensive measure you did on behalf of the community to make sure that bad guys didn't do things with the term. As you know, I have committed publicly to working with the IETF on the administrative restructuring issues. Over the coming year, I hope we can work out how best to handle matters such these, but at best the document ought to recognize this fact of life and that it will be necessary to address these matters in due course going forward. The fact of life is that the community has, after extended discussion in an open process, decided to restructure administrative activities so that the Internet Society will house the IASA and work with contractors such as Foretec. As you've pointed out, we will have to work carefully to make sure that a transition is smooth and and careful. But, ownership should not be an issue. Any IETF assets that may have been created by CNRI are simply work for hire: we paid for those assets out of our pockets. I appreciate your statements that CNRI has helped subsidize the IETF at times and that this isn't a big money maker, but I'd also point to the US$16,920,928 we paid in meeting fees from 1997 to 2004. Property concerns should be *off the table* as we address these matters in due course going forward. Best regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? IPR rights and all that
6. The IASA, on behalf of the IETF, shall have an irrevocable, permanent right of access and later use to all data created in support of the IETF's activities, including the right to disclose it to other parties of its choosing. ... Reasonable, but I want to be sure that the data rights also include rights to, for example, the domain name ietf.org. Some legal person should advise on how to state that. Brian How about all data and other intellectual property? Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: iasa-bcp-01 - Open Issues - Pre-nuptials
It's kind of a good fences makes good neighbors kind of thing. but Frost was arguing just the reverse http://www.bartleby.com/118/2.html (in case anyone is confused - in pointing the above out I am not saying anything about the need for a Pre-nup agreement in this case - just showing I read Robert Frost (and heard him speak once) a long time ago) You can still hear him talk: http://town.hall.org/radio/HarperAudio/012294_harp_ITH.html Includes many hits, including The Road Not Taken, Provide, Provide and Death of the Hired Man. Regards, Carl Sorry for the ancient audio formats ... its been a while. :) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: created IPR
The specific term is work for hire. All data, created software, etc must be considered the result of work for hire and as such is the property of ISOC in trust for the IETF. I agree, and would simply add whenever possible. Remember, this is not the contract, it is guidance to the folks that make contracts. You can say work for hire or openly available or whatever makes the intent clear. There will be exceptions ... this simply instructs those folks to try to err on the side of open and if not, please give a good reason. Let's not be too prescriptive with words like trust and work for hire as those are terms of art and have special meaning. Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: IASA BCP: Separability
Yes. I have a feeling that even with the BCP approved by the IESG and by an ISOC Board motion, we would still need a piece of paper with ink signatures - it might only say that the IETF and ISOC agree to the terms of the BCP - it might also contain termination clauses about money and IPR, if the termination clauses aren't in the BCP. In any case it would be very short. In terms of the ink, you can go that route if you want, but having this bcp go through the entire public bcp procedure and then get voted on by the isoc board in a meeting with minutes makes a pretty conclusive case that you have an agreement. I don't think a judge is going to throw this out because you didn't use a #2 pencil or blue ink. :) In terms of clauses, it seems to me that if you're going to do termination clauses, or anything else with that kind of substance, they need to get into the BCP. You really want a single chartering document for the activity. And, my sense of the room is that people aren't going to be happy to put this doc to bed only to start a similar exercise right up. :) Let's get the substance into the one doc. You brought up termination clauses. If you're doing that, you probably want a mandatory arbitration/mediation or other conflict resolution clause. You could certainly leave those both out and have a nice agreement, but it sort of sounds to me like enough people want to face those issues now. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 5
Works for me to. Harald suggests Suggested edit: Change Note that the goal is to achieve and maintain a viable IETF support function based on meeting fees and designated donations. The IETF community expects the IAOC and ISOC to work together to attain that goal, and recognizes that doing so will require striking some sort of balance. to Note that the goal is to achieve and maintain a viable IETF support function based on avaiable funding sources. The IETF community expects the IAOC and ISOC to work together to attain that goal, and recognizes that doing so will require striking some sort of balance. works for me Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: created IPR
2.2.6 currently reads: The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld or limited in any way by ISOC from the IETF. You could simply append: As a matter of principle the IAOC and IAD should ensure that any contracts for IASA clearly designate that any software, databases, and websites should be openly available, including open source for software and a machine-readable format for databases, whenever possible. [ Charset ISO-8859-1 unsupported, converting... ] on 2004-12-02 9:58 am Brian E Carpenter said the following: Scott Bradner wrote: the new draft asks: Do we need wording about the ownership of IETF tools and data? We have some text (in Section 2.2) about IPR, but does that fully cover tools and data? fwiw - my intention in the text that is now 2.2(6) was to cover the tools and data Subject to legal advice, that seems OK to me. But maybe we should make a word or two to make the rights irrevocable. I'm not sure if the current text clearly implies that tools created for the IASA by a contractor, and data collected for the IASA by a contractor shall be openly available. And maybe a separate point, would it be desirable when we talk about tools and data in particular, to specify that the IASA must ensure that tools developed by a contractor for the IETF or IASA must be open source, and that data collected by a contractor for the IETF or IASA must be available in a documented machine-readable format? Or is this to go into too much details... Henrik ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: created IPR
Scott - I did postfix whenever possible and prefix as a matter of principle ... this simply says if you're not going to do it that way, please have a reason. Regards, Carl Carl suggests: 2.2.6 currently reads: The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld or limited in any way by ISOC from the IETF. You could simply append: As a matter of principle the IAOC and IAD should ensure that any contracts for IASA clearly designate that any software, databases, and websites should be openly available, including open source for software and a machine-readable format for databases, whenever possible. openly available is different than making sure that the source is available to the IETF during or after the contract I'm not sure the IETF should insist that all software is open source (I am sure that any software written by someone being paid to write the software by the IETF must be available for the IETF to move to another contractor) I do not have a real strong feeling here but it seems that this text would limit the flexaility of the IAD to get the best value for its $ Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: IASA BCP: Separability
At 3:41 PM +0100 12/1/04, Brian E Carpenter wrote: Yes, I've always assumed there will be an MOU between IETF and ISOC, both to recognize the BCP when we have it, and to make explicit some of these boundary conditions. This is interesting, because I had not assumed that there would be a separate MOU... Who do you think would negotiate the MOU on behalf of the IETF? And who would sign it? I must admit, I share Margaret's reaction. I assumed the BCP was the governing document and wouldn't necessarily have to be supplemented with a codified set of supplements and interpretations. :) Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
As the maintainer of the Linksys Blue Box Router HOWTO, I am quite well aware of this fact. And if my objective were to have exciting adventures in system and network administration, I would have reflashed my Linksys long since. I don't want to have exciting adventures in system and network administration. I want my home network to just freaking *work* so I can concentrate on the problems where my time is most valuable. Hmmm ... I'm quite happy with the stability of my sveasoft code and find that staying up with their latest releases is pretty trivial and keeps my box humming just fine. What I found exciting about being able to reflash my linksys is that I could have a real router (sort of), *not* have to be an expert, and it *works*! No more difficult than clicking on the software update button periodically. Just one user's experience ... your horror stories may vary. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: an attempt at some principles
in these principles I have not directly addressed the feeling of some people that the IETF needs to be able to blow the bolts (as I put it a while back) with the ISOC quickly if things go bad in some way. I have not done so not because I want to dismiss or ignore such feelings but because I have not figured out a way to express it if I take into account the fact that the IETF cannot actually go it alone anytime soon because it does not have the cash flow from meeting fees that would support an independent IETF - suggestions welcomed How about: section title=Community Consensus and Grant of Authority t The IETF is a consensus-based group and authority to act on behalf of the community is an act that requires a high degree of consensus and the continued consent of the community After a careful process of deliberation, there is a broad-based community consensus to house the IETF Administrative amp; Support Activities (IASA) within the Internet Society, which is reflected in this Best Current Practice (BCP) RFC./t t Termination and change. Any change to this agreement shall require a similar level of community consensus and deliberation and shall be reflected by a subsequent Best Current Practice (BCP) RFC. /t /section A termination clause is standard in any agreement and this one simply says if you want to change this, get another bcp through the process. This doesn't address the and we want to take our money with us issue, but I believe that could be addressed elsewhere or not addressed at all. Either way works for me. 2/ The IAD, IAOC and the ISOC shall not have any authority over the IETF standards development activities. That's almost true, but you probably need to address that the fact that ISOC does play an important role in the standards process, a role that is not changed by this document. 7/ The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld by the ISOC from the IETF. how about withheld or limited in any way? Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Executive Director
There is an obvious question that at least for me drives the answer to whther the IAD is the IETF Executive Director. As currently practiced / defined, is the IETF Executive Director a full time job? Scott Bradner could probably answer more definitively, but I believe our process documents and other RFCs refer to a role, not a job. Basically, there are a few times in which you need to contact the IETF and the words IETF Executive Director means the full time staff shall ... and go find the person who has that title. (Barbara Fuller, as the lead person on the Foretec IETF Secretariat is our current Executive Director.) It seems to me that one of the goals of the whole AdminRest exercise has been to move overall management responsibility for IETF admin. and support activities (IASA) from contractors to a program manager, which is what this BCP is all about. As such, it seems that where documents refer to IETF Executive Director that should become (via a paragraph in this BCP) a pointer to the IAD or other appropriate position as further pointed to by the IAD. If it is a full time job, then clearly it should not be combined with the IAD. THis implies that we will need budgeting to contract / hire this person in addition to the IAD. So far, the contracting philosophy has been one and only one person as a full-timer. Everything else is a contract. If we're going to go 1++ (or designate a contractor as a named position), that probably needs to be worked out. My personal feeling: don't tie the hands of your iaoc/iad until they can start looking at contracts and how they might/should be let. Unless explicitly delegated with the consent of the IAOC, the IAD will also fill the role of the IETF Executive Director, as described in various IETF process BCPs. My own opinion (ymmv) is leave the text as is and strike the editorial note. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Executive Director
That seems simple enough when put that way ... then leave the executive director totally out of this BCP or specify that the IESG names that person. No need to pussy-foot around the issue. :) Carl Carl == Carl Malamud [EMAIL PROTECTED] writes: Carl It seems to me that one of the goals of the whole AdminRest Carl exercise has been to move overall management responsibility Carl for IETF admin. and support activities (IASA) from Carl contractors to a program manager, which is what this BCP Carl is all about. As such, it seems that where documents refer Carl to IETF Executive Director that should become (via a Carl paragraph in this BCP) a pointer to the IAD or other Carl appropriate position as further pointed to by the IAD. I think the IESG's concern here is that they, rather than the IAOC would like to designate who the executive director is. The executive director is very involved in making the IESG and process functions run smoothly. It seems like significant friction would be created if the executive director was not someone the IESG was comfortable with. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Issue: Budgeting process and financial oversight
I actually think everybody is in agreement. The ceo definitely does the budget. There is no doubt about it. And, the paragraph you quoted was actually one that is fine as is. But, there are a few places in section 3, as Bernard pointed out, that we're making some unnecessary distinctions between iaoc and iad. There is a board, which is responsible for iaoc. It has the buck stops here responsibility on how the iasa operates. The iad is the officer of the activity/business/entity and carries out the policy as an executive, as well as providing the staff support that the board needs to make decisions. I think everybody agrees on that. All I think Bernard is objecting to is some sloppy draftsmanship. Why don't we let Bert/Rob try and clean that up in their next draft? I know they've got this section down as an issue. I suspect they can clear this section up with a little surgery. Carl it doesn't make sense to me. but then the corporate boards I have served on (Unicode Consortium and .no registry) seem to function very much in the mode of oversight and strategy direction - it would be bizarre for either of those boards to attempt to create a budget; in both organizations, that's the administration's job, as represented by the CEO - including answering all the hard questions about why the budget looks that way, and modifying the budget based on feedback from the board on what strategy it wants supported. Quoting from section 3: The IASA will initially consist of a single full-time ISOC employee, the IETF Administrative Director (IAD), who will be an officer entitled to act on behalf of the IASA at the direction of the IAOC. The IAD is likely to draw on financial, legal and administrative support furnished by ISOC support staff or consultants. Allocation of costs for ISOC support staff and consultants will be based on an actual expenses or on some other allocation model determined by consultation between the IAOC and ISOC. I think that is the right division of labour (the IASA *does* the work, the IAOC *oversees* the work, and the IAOC is *not* part of IASA). So any power that implies *doing*, including chartering committes that help define or refine the support for the IETF, should be given to the IAD, not to the IAOC. Any committee that does *oversight* (for instance an audit committee) should be chartered by the IAOC. Your mileage may vary. Harald --On 24. november 2004 16:17 -0800 Bernard Aboba [EMAIL PROTECTED] wrote: It seems to me that in most of section 3 where it says the IAD shall, you could probably simply change that to the IAOC shall. For example: The IAD may constitute special-purpose, chartered committees to bring in expertise (on topics such as finance, IETF process, or tools), to engage This simply becomes The IAOC may constitute ... Does that make sense or are people envisioning the Office of the IAD having some more distinct powers and responsibilities rather than simply reporting to the board? Yes, this makes sense to me. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Issue: Budgeting process and financial oversight
Bernard - Good comments. I went back and re-read section 3, and I agree that it is somewhat unclear. (That's sometimes good, of course, but probably not in this case). From what I read, the idea is that the IAOC sets policy: it has a large say in how finances are done, reporting to the IAOC is done in a way that they can operate the IASA as a seperate business unit, etc... That says to me strong committee which is a bit more than oversight. The IAD is a member of the IAOC. (IMHOW, this person should have a vote, but ymmv ... I've been on boards where I'm a voting executive and on boards where I was non-voting, and it was always frustrating to be have only a half-voice at the table. :). It seems to me that in most of section 3 where it says the IAD shall, you could probably simply change that to the IAOC shall. For example: The IAD may constitute special-purpose, chartered committees to bring in expertise (on topics such as finance, IETF process, or tools), to engage This simply becomes The IAOC may constitute ... A lot of the stuff in the IAD responsibilities and IAD committees becomes IAOC And, a separate section merely states that the IAOC shall hire an IAD who will serve as the chief executive and be a voting/non-voting member of the committee and shall serve as the executive director/staff for the committee. Does that make sense or are people envisioning the Office of the IAD having some more distinct powers and responsibilities rather than simply reporting to the board? (In a corporation, it is rare for the ceo to be defined in the chartering document, except for a mention that they are a voting/non-member of the board and, as an officer, have certain fiduciary and other legal roles (e.g., can sign a check)). Things like shall do the budget aren't usually stated at the level of the chartering document as a job duty, they are simply a responsibility of the entity as a whole as represented by their board of directors. Regards, Carl In reading section 3, I believe that there are some issues with respect to separation between the IASA and IAD responsibilities. My overall comment on Section 3 is that co-mingles sections relating to the responsibilities of the IAD and the IAOC. Since the IAOC constitutes the management, while the IAD is an (ISOC) employee, these responsibilities need to be separated, both editorially and logically. I would prefer if Section 3 focussed solely on the IASA, and another section was devoted to the IAD and the associated support functions. However, beyond the editorial separation, I think the logical separation of responsibilities is not well articulated in Section 3. The IAOC is the body that reviews the operation of the IASA as well as the IAD. In order to ensure that the IAOC can carry out that mandate it needs to maintain the oversight function independent of the IAD. Section 3.2 seems confused on this point: The IAD may constitute special-purpose, chartered committees to bring in expertise (on topics such as finance, IETF process, or tools), to engage volunteers in IASA activities, or to gain additional perspectives. These committees may consist of subsets of the IAOC, IAB or IESG, selected IETF participants, or external experts, depending on the need. These committees are advisory in nature -- the IAD is responsible for the outcome, including presenting and supporting any decisions or work items to the IAOC and the IETF community, as appropriate. While it is appropriate for the IAD to attend finance committee meetings, the finance committee function is inherently a responsibility of the IAOC, given its role in review of financial reports as described in Section 3.3. Therefore it seems like the finance committee function is part of the IAOC, not the IAD, in order to ensure proper oversight. Similarly, if the desire is to keep the IETF process separate from the IASA, then the IAD should not be chartering committees relating to the IETF process. Given this, I'd suggest that somewhere in Section 3, it should be stated that the IAOC can form subcommittees in order to help it carry its work, such as the finance committee. I'd also suggest that the timeline described in Section 6, describes a throw it over the wall budgeting process that is unlikely to prove workable in practice. An arrangement that brings together input from the IAOC, the IAD and the ISOC from the start is likely to work better. The IAD is likely to draw on financial, legal and administrative support furnished by ISOC support staff or consultants. Allocation of costs for ISOC support staff and consultants will be based on an actual expenses or on some other allocation model determined by consultation between the IAOC and ISOC. In practice it is likely that the IASA will incur considerable ISOC overhead, and therefore that the overhead allocation (including the overhead associated with fund raising) will turn out
Re: AdminRest: New version of IASA BCP document available
this is far to proscriptive - I do not think that the authors of this document or the general IETF community are accounts - lets establish the requirement that funds be available when needed but not try to dictate the best way for that to be done - let the accountants figure that out I think the principle is more than available: it's a matter of who they belong to. How about a simple 1-sentence addition: Funds collected on behalf of the IETF and IASA shall be clearly identified as such and shall be used at the direction of the IAOC. (There are other limits in the doc on what the IAOC can do and on how the budget process works, so this sentence states that the funds belong to the IETF and shall be spent as such, subject, of course, to the various caveats on ISOC approval, process, etc...). Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: New version of IASA BCP document available
[EMAIL PROTECTED] wrote: one example from section 3.1 - Although the approval of the ISOC President/CEO or ISOC Board of Trustees may be required for some contracts, their review should be limited to protecting ISOC's liabilities and financial stability. [many other messages] allison wrote: After the BCP has the full support and approval of the IETF community, the IASA and IAOC will be formed, and it will be part of the ISOC organization. I'm concerned that what you're suggesting here is just not good organizational practice. At the end of the day, functional differentiation is necessary. The IAOC and IASA have a task: the work needed for IETF operations to be accomplished, which include the full review and decision-making on RFPs at each cycle. The ISOC folks (BoT) has its own manifold tasks. IAOC and IASA do not perform the ISOC BoT's tasks, and the ISOC BoT should not peform IAOC/IASA tasks. It's not a matter of ruling out informal discussions, but of making organizational clarity. We're working toward a shared specification that the ISOC President/CEO and BoT representatives have voting representation in the RFP decisions, and that is the organizational structure. Saying that there doesn't need to be an bright line, that there doesn't need to be functional differentiation, is contrary to our goals in working on all this structure in the first place. How about this instead: Although the approval of the ISOC President/CEO or ISOC Board of Trustees may be required for some contracts, in order to provide a single point of focus in support of the IASA, primary responsibility for the evaluation, review, and negotiation of contracts and other IETF administrative and support agreements shall rest with the IAOC. This provides a simple metric (primary responsibility for the evaluation, review and negotiation ) on which corner cases that arise in the future can be judged. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: Finances and Accounting
Hi - I'm not aiming this note at anybody in particular, but I sense some confusion about some basic accounting principles. I hope nobody will be offended by a brief tutorial. An income statement shows expenses and revenues over a period of time, often one year. When I hear full allocation of expenses and revenues in order to have a good financial picture of the IASA, I imagine an income statement that looks like this: Income Unobligated general revenues$100 Revenues specificaly tagged for IASA$100 General In-Kind Contributions $ 50 In-Kind Contributions for the IASA $ 50 Total Revenues $300 Expense ISOC meeting expense$ 50 IASA meeting expense$ 50 ISOC other expense $ 20 IASA other expense $ 20 General expense $ 60 Depreciation$ 20 Total Expense $220 Note the listing of non-cash (in-kind) contributions under income. Depreciation writes off a portion of the value of the equipment each year to reflect the lower value of the asset over time. This is accrual-based accounting, which is what Fred mentioned. This income statement meets the criteria I've heard on this list: you can break out the IASA-specific expenses and revenues, allocate the general expense and depreciation, and come up with a pro-forma income statement for the IASA activity. The basic message is: please don't lump everything over into general administrative costs, try and allocate those costs that can be identified into IASA specific categories. Where I see the confusion is on the concept of the balance sheet, which lists assets and liabilities at any point in time. You can imagine two balance sheets: Assets: Bank Account $200 Physical Assets$100 Total Assets $300 Liabilities Funds obligated for the IASA activity $100 Other Liabilities $100 Goodwill and Equity$100 Total Liabilities $100 Alternatively, one could do this: Assets: General Bank Account $100 IETF Bank Account $100 etc... etc... The gooodwill and equity line is the excess of assets over liabilities. What I'm not hearing a consensus on this list about is the concept of what to do with the balance sheet On the one hand, I hear things like quarterly payments and shall be deposited into the account. On the other hand, I hear that this overly constrains the accountants. The answer is you could do this either way. Even if the financial statements don't break things out into seperate bank accounts, the IASA can still receive a management accounting report that shows how assets, liabilities, expenses, and revenues are allocated. You can also add the requirement of seperate accounts on the balance sheet. That makes accounting a little bit harder, and you spend a bit more on things like bank fees, bookeeping time, and other transaction fees, but it isn't a huge deal. What I've heard on this list is quite a bit of talk about generally accepted accounting practices. I don't believe there is any doubt that ISOC practices those practices and it is a no-brainer to request allocation of line items. The request for periodic transfers of funds based on the budget process, the seperate accounts, etc... are not unusual for a self-contained profit center in a company. So, that can be done as well. The question for the IETF is whether the request for seperate accounts is important to you and should go into the BCP. Before everybody jumps in: the latter seems symbolically important to some folks and maybe the question is political and should be handled as such (e.g., don't ask is this optimal but ask is this important enough to some people that this is a way to get consensus and move on.). $0.02, YMMV. Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: Finances and Accounting
This relates to my previous comment in response to Geoff. It's all about how to smooth cash flow, given that both income and outgoings are bumpy. If, in practice, some help from the IASA account is needed to smooth ISOC's cash flow temporarily, that is fine by me but I'd like it to be transparent and explicit. It should show up in IASA's accounts and in ISOC's IETF pillar as a debt from ISOC to IASA (or the opposite, if it's IASA that has a cash flow issue) but it would be a wash externally. However, it should be constrained in such a way that it is only for smoothing, and cannot be used to cover a real cash shortfall. I agree that some accounting type person should review the text. Brian This sounds to me like people would like this to be based on a seperate account and pre-arranged quarterly transfers (pre-arranged meaning whatever was agreed by the budget process as subsequently modified by any supplementary agreements during the course of the year). In addition there is a requirement that tagged donations are promptly accounted for and one that (to the extent reasonable) a full allocation be made on other isoc expenditures that also benefit the IETF. The cash issue, however, is kind of a red herring. Assuming solvency, this is a wash to the outside world. My point is that cash is only one of many accounts, and there are other asset accounts such as operating funds and other iasa accounts. You're getting into specific bookkeeping directions here. It doesn't seem reasonable to create the chart of accounts or develop the cash management policies in this forum. Instead, more general policies that establish principles are a better level to be at. Things like periodic transfers of isoc donations during the course of the year according to the pre-arranged timetable established during the budget process, full allocation of expenses, and ISOC shall establish and maintain prudent cash management policies to insure the continued viability of the IASA are the level I think we should be talking. The basic point seems pretty simple: the ietf seems to want a seperate set of accounts so that iasa will have an accurate financial picture and a degree of financial control in regards to ietf-specific activites. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Section 5.3
The second paragraph in this section says: If ISOC directly funds any other IETF expenses, such as the IETF share of ISOC's liability insurance premium, this will be documented together with the other IASA accounts. I'm not really sure what this means... There are some complexities to this budgeting process that aren't captured in this document, and I don't think that they should be. However, calling out one particular point (such as insurance) really begs the question of why other things that fall into this category are not called out. I would prefer that we simply delete this paragraph from the BCP. Hi Margaret - I think the point here was not to single out insurance but to say that the IETF would like to see what is known in accounting circles as a full allocation. That means that some attempt is made in the books to allocate general expenses (such as insurance) among various programs. An alternative accounting model is simply to calculate overhead (e.g., unallocated expenses) and use some metric (e.g., total expenses by pillar or activity) to do the allocation. That's kind of what we have today (of $2m in revenues, $600k is lumped into the overhead category). I think what the paragraph in the bcp intended to say is the former not the latter. It does seem likely to me that there will be a single ISOC DO insurance policy and that the costs of that policy will be allocated to the ISOC standards pillar as part of the overhead. But, I don't understand the point of calling out this particular expense as something special... There are other costs (such as paying a qualified accountant to figure these things out) that will also fall into this category. Might it read better something like this? In the case of additional direct expenditures by ISOC which benefit the IETF and other activities, ISOC shall attempt to allocate such expenses by activity, allowing IASA to gain an accurate view of the true cost of support activities. And, to the accountants: don't lump all general expenses into a ga budget line: at least attempt to break stuff out by program if it makes sense to do such an allocation. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: BCP and IASA IRTF support
Hi Michael - I actually looked at this issue in drafting this report. bcp8 seems to place the irtf in the inner ietf circle (e.g., iesg, iab, etc...). And, as Harald notes, their support needs are fairly minor. So, I lumped their funding needs in the misc. category of the ietf financials. We have enough on our plate for now, so the structure and funding of the irtf just didn't seem worth calling out as an issue. At $1000/year, seems like one of those things we can not worry about for now. Regards, Carl [ Charset ISO-8859-1 unsupported, converting... ] --On s?ndag, november 14, 2004 15:47:00 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: Michael Richardson wrote: ... Of the RG people that I know, they all attend IETF. Of course, I might never meet the RG people that don't attend IETF. If so, who are they? There are such people - I know of at least one person who was in DC on the Saturday before the IETF for an RG meeting, and who drove home on Saturday night. But I don't think it's relevant - the question is whether RG support is on or off the IETF budget. In view of the budget numbers Harald gave us, the answer surely has to be off at present. That doesn't mean IRTF support should be out of scope for IASA in principle, though. If the IRTF support is on the order of USD 1000 per year, it really doesn't matter to the budget whether it's on or off. As a matter of principle (because I regard the IRTF as part of the large tent IETF that RFC 3716 described), I think it should be on, and we can choose whether to give any money to it in a specific year or not. Telling the IRTF that they need to set up their own funding structures if they need support for their activities seems not right to me. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The Clerk function and Standards throughput and quality
This is one of my more general objections to the report -- in areas like the personnel one and how staffing roles are presented, it appears (intentionally or not) to be organized in such a way as to impede community understanding of what is being proposed. I'm not sure what you're referring to here, John. You understood it. I assume the rest of the community is at least as smart. This is a pretty hard community to impede, so I didn't try. Rather than tell you, or other members of the community, what to think, I tried to give you some additional facts. You, as well as everybody else, are perfectly able to draw your own conclusions. (And, should you wish it, I am available to talk to you or any other member of the community to futher elaborate any of these issues ... I'm even able to make concrete recommendations if you'd like to hear them.) As you rightly pointed out, there are more than one staff roles that support the IETF. You can do that as contractors or as employees. It just doesn't matter in the long run, in theory. In practice, it depends on who you are able to attract who might want to work for you. And, as you've stressed a few times, the first step is to get the administrative director (IAD) hired. If you have specific suggestions for that job description, that would be quite useful. You've mentioned several times you didn't like the one in the report, so this would be a good time to fix that flaw. Thanks! Carl , ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Administrative Reorganization: What was that problem anyway?
John - Would it be fair to summarize your note by saying it is a lightweight scenario A? E.g., simply take one action: hire an administrative director for the IETF and have that person live at ISOC. RFPs, budgets, etc... will all flow out of that initital action and there is no need for a grand restructuring. Let me know if you think that is a fair assessment. I think that is an important option that people should keep in mind and wanted to make sure that I don't oversimplify your analysis. Regards, Carl In trying to parse both Carl's document and the general situation in the last few weeks, I've found myself getting increasingly dissatisfied with the document and the discussion, mostly with regard to ways in which the document has constrained the discussion and was, itself, constrained by RFC 3716 (the AdminRest report) and what it is believed to say. As a member of the committee that put 3716 together (but speaking only for myself), I think it is subject to the same sort of rules that apply to the relationship between our model or requirements documents and subsequent actual protocol work: if we discover in protocol development that the models are inappropriate or unimplementable, we change the models rather than considering ourselves locked to them. In fairness to Carl, this is an option he didn't have: the contract held him fairly closely to RFC 3716. Disclaimer: the comments below, and in my next note, draw, without attribution, on a lot of virtual and physical in-the-hall conversations. I'll let the contributors identify themselves if they like, but I probably could not do so accurately and don't think it would be particularly helpful at this point. I have been working on these notes for a week or so, and, while related pieces have shown up in on-list comments, I've changed my mind several times about whether to send it. A few comments in the last 72 hours have convinced me it is time. While I think the complexities of Carl's simple solution calls for reconsidering some of the conclusions of 3716 (or at least a more intensive community review of those conclusions), that document hints at the issue here in its section 4.1: o nevertheless, it remains a non-goal to create an organizational entity that exists simply for the purpose of continuing to exist. This should be executed with the minimum formality needed in order to address the identified requirements. Stripped of a good deal of speculation about organizational structures and arrangements, the key to 3716 and the concerns that surrounded it seems to me, again in retrospect, to be exactly two problems: (1) For a number of policy and budgetary reasons, having two revenue sources that have to be kept isolated from each other lies on a scale between suboptimal and nuts. One of those streams is the meeting registration fees and their allocation to secretariat support as well as meeting costs. The other involves donations and other funds collected by ISOC and dedicated to non-Secretariat IETF support. (2) The IESG perceives that they are not getting adequate support for their work, and the standards process more generally, from the Secretariat and that, despite considerable effort, there has been little progress on solving that problem. The efforts to do so go back many years, including six to eight years or more of unsuccessful attempts to work out a statement of relationships and authority, in the form of an MOU, with CNRI and then with Foretec.As I have mentioned in another note, the key difficulties in that process seem to hinge on fundamental philosophical disagreements about the nature of the relationship. Independent of the causes, details, and how we got here, some fraction of the IESG and IAB now believe that the relationship with the secretariat has become sufficiently poisoned that a significantly better relationship is not possible with the existing Secretariat and its management. It is worth noting that, from the Secretariat's viewpoint, it is likely that uncertainties about the administrative reorganization process and their future have made it impossible to do the job well and, in particular, to do any long-term planning. From that perspective, part of the problem is that the IETF has put them in a position of making it impossible to do long-term planning, and then complained that they are not doing long-term planning. But the problems that are impeding the IESG's work and the standards process were significant long before the reorganization process began. Those two issues, especially the second, have a fairly clear negative impact on our ability to produce good-quality standards
Re: IETF Administrative Reorganization: What was that problem anyway?
John - Let me try again. I wasn't trying for debating points. It seems to me that you said that my report covered a lot of ground that doesn't need to be covered. And, that the overall focus of the administrative restructuring is misconceived, trying to solve a set of problems that don't necessarily exist and perhaps trying to solve those problems in a non-optimal way. In other words, the exercise is misguided. Not trying to put words in your mouth. I then jumpted on the one action that it seemed you might endorse (which is hire an administrative director). Again, the point you're making is, imho, an important one, and I'm trying to translate that into terms that I can understand, which is what specific actions might be taken. Regards, Carl --On Wednesday, 15 September, 2004 06:59 -0700 Carl Malamud [EMAIL PROTECTED] wrote: John - Would it be fair to summarize your note by saying it is a lightweight scenario A? E.g., simply take one action: hire an administrative director for the IETF and have that person live at ISOC. RFPs, budgets, etc... will all flow out of that initital action and there is no need for a grand restructuring. Let me know if you think that is a fair assessment. I think that is an important option that people should keep in mind and wanted to make sure that I don't oversimplify your analysis. Actually, no, for two reasons. The important one is that the main point of my note is to describe some real concerns about what we are doing here and why, what the priorities are, whether we have lot sight of the real issues, and so on. Characterizing it in terms of any particular solution or scenario misses the whole point. Actually, while I'm sure you didn't intend it that way, your summary is reminiscent of the notorious debating tactic of ignoring all of the main points of an argument, seizing on a minor detail that can easily be misinterpreted (if necessary) and then attacked, and thereby distracting the audience from those main points. In terms of actual proposals, I quite deliberately did not include one, not because I wanted to start people guessing, but because I think a review and discussion of problems, goals, and principles here would be much more useful than plunging deeper into scenarios, if only to give us a stronger basis for evaluating whether a given proposed solution would solve an identifiable problem at acceptable cost and risk. If the community can have that discussion in a serious way, then I'll post that other proposal. If we can't, then the only way I see any of this moving forward is by an assertion of imperial authority and, to be very blunt, I don't need to spend my time on an IETF that has to make decisions by imperial authority or that permits it to be done. And IETF like that is, IMO, already dead, regardless of what mechanisms or monuments it erects administratively. However, fwiw, I think the sort of lightweight scenario A you describe and somehow inferred from my note would be a mistake. It brings to mind an old cartoon that I assume you and many members of the community have seen in some variation: complex equations at the top, complex equations at the bottom, in between is the phrase and then a miracle happens. The dots really do need to be connected, and hiring someone, with more or less the right skills, under a more or less adequate job description and with no definition of how that person is supervised, given direction, etc., and then expecting RFPs, budgets, etc... will all flow out... requires a miracle for the intervening steps. If one were to believes in miracles, they should probably be saved for more important and intractable problems. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: admin director (was The other parts of the report..)
So, if be specific about what this job is about is going to be delegated from community review and approval of a proposal that is presumably based on Carl's report to a team that writes a job description, then I think the community needs to review and approve that job description before any hiring effort starts. There is a sample job description in Appendix E. It is written in a certain style, and I know there are other ways to write job descriptions. If somebody else wnats to take a crack at it, that would be great. I'm working on an -02 rev and comments are most welcome. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: first steps (was The other parts of the report...)
Hi John - At the risk of being too specific about this, the meeting planning function(s) and the [standards] secretariat one(s) have almost nothing to do with each other --other than, in our case, some rather important history. Agreed, with the addition of Steve Crocker's point about the meeting agenda being part of what you call the [standards] secretariat and what I termed the Clerk's Office. To further complicate things, I personally don't think the IETF has yet figured out enough about what it really wants from the secretariat part of the function and reached enough consensus on that to justify any RFP-writing. I agree with you. My personal view is that a better strategy for that piece is to attempt to negotiate a sole source contract with CNRI. I don't think we understand the process (indeed we probably haven't defined the process enough) to do an RFP. Just my view, and there are reasonable opinions to the contrary. Now, if one separates out the tasks and constructs the RFPs and evaluation process properly, presumably nothing would prevent one organization from coming in and saying we actually have all of these skills, can justify your giving us the whole cluster of tasks, and can give you a price break if you sign up with us for more than one of then. That is actually done fairly routinely in some settings. If there are viable candidates, it would give you what you seem to be looking for below without imposing a rather strange constraint on combinations of skills. That's kind of how I wrote the RFP. Again, just my personal view, it didn't seem prudent or wise to attempt to change all of our horses in mid-stream. Of course, if we'd like to stick with CNRI with some functions, it is important that we begin a dialogue with them. It isn't easy for them since they aren't sure what the IETF would like to do. I've seen several comments that the mailing list or web presence functions seem pretty straightforward to issue an RFI (a request for information) to see what our options are. By drawing a broader brush than just mail or web, I think we could get a pretty good idea of what kind of support we might get in the way of good proposals. That's why I recommended a broader network presence function be considered. In summary, I outlined three pieces: 1. meeting planning 2. core network 3. clerk's office We could do sole source procurement on 0-3 of those pieces, or an RFP on 0-3 of those pieces, or we could pick a different decomposition. I don't think you can do both a sole source procurement and an RFP on the same piece, though, so that is a decision point. And, there is a bit of urgency to make that decision since it is hard to move forward during a transition period. (I used the word urgent instead of, say, panic ... we do have some time to get this right, but it would be nice to move along with all due deliberate speed.) Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: archives (was The other parts of the report....
Ole - I agree that the IETF has a special responsibility to properly present the archive ... we can't simply lay a big ftp directory out there and make no efforts to show how a particular file fits in context. On the other hand, ietf.org could certainly beg/borrow/steal some of the work being done in places like potaroo.net and watersprings.org. Some things that could be done include: 1. Add some clear text that explains the role of the i-d historical repository 2. Link to previous and future versions of a draft (including any resulting RFC) 3. Link to any relevant mailing list discussions 4. Find related drafts or place the draft in the context of a working group 5. Add a very clear indication that the particular document in question is Expired As to citing work-in-progress instead of the final standard, well, hmmm ... if we don't have our own repository, there isn't much we can do. On the other hand, if a customer/reader/journalist were able to go to ietf.org and pull up the document in question, perhaps it could be really clear what the status is? If we want to make clear that a document is expired, it is much better to say so rather than pretend it doesn't exist. Regards, Carl - Vendors are stupid and will claim compliance with a work-in-progress document instead of a final standard. This is very bad - Drafts often change along the way (including being completely discarded as bad ideas) and we should discard such snapshots in case someone gets the wrong idea from reading one. Needless to say, I don't really buy these arguments. As someone who publishes articles where the only existing reference might be an ID at the time of writing, I believe there are better mechanisms we could use (as we do with RFCs and the Obsoletes/Obsoleted by tags). Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Academic Research and Technology Initiatives, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: archives (was The other parts of the report....
You could do an opt-out period, say 6 months, before publishing the database. With sufficient publicity, say periodic reposting of the opt-out announcement on the ietf list, this seems to strike a balance between the unspecified policy of the past and a new policy for the future. This seems like a more-than-sufficient amount of care given the fact that the data is already available in numerous locations on the network. However, I don't think you even need to do an opt-out requirement. Times change. The data exists on the net. The IETF needs to keep a full archive for legal reasons even if it doesn't allow FTP access by the public. Why should lawyers with subpoenas get access to the database and members of the community can't? We should simply remove the access control. Regards, Carl bil sez: ah... but said RFC did not exist at the time my IDs went out. and my cursory perusal of said RFC seems to indicate that it is mute on materials submitted into the IETF process in times that pre-date said RFC existance. fully agree - that was not my purpose in providing teh pointer - I just wanted you (and others) to know what today's rules are that said, it could be that the 40,000 or so legacy draft authors won't care, but it would be sound hygiene to ask them if they mind if RFC 3667 rules would apply to their contributions. you are kidding - right? Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Explosive bolts [Re: Options for IETF administrative restructuring]
like many things outside the core technical field, these things are hard, and harder than they look, and hard enough that you need a better lawyer. as long as IETF remains an unincorporated association, i think you need every new IESG and IAB member to add their signature to all current MoU's and other agreements. but you should find a lawyer. a better lawyer than the one who was standing by last time this stuff was discussed or signed. -- Paul Vixie What Paul says is sort of true. Traditionally, at common law, all members of an unincorporated association were, in certain circumstances, personally liable for the actions of the association. However, under the 1996 uniform nonprofit unincorporated association act, which has been passed by 9 states, unincorpated associations can, under certain circumstances, have standing, limitations of liability, and the ability to hold and transfer property. The -01 rev of my draft, to be released shortly, contains more details on this mechanism. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: On the difference between scenarios A and B in Carl's report
The thing that left me most uncomfortable with Scenario B as described was that it presented a smorgasboard of options (here are ten menu choices - take your pick), where some of them (the MoU) were totally obvious, and some had (in my mind) severe disadvantages. So we can't say we go for scenario B and have the discussion be finished, we have to be able to say Options 1, 3, 5 and 7 make sense, the rest does not, and besides, here's option 17 that wasn't in the original document. There are 7 mechanisms listed, but in no way did I expect some substantial number of them to be adopted. Indeed, they are listed as straw-men and I did not make a recommendation. The idea was to illustrate a range of options and I left the hard part (deciding what to do) to the community to decide. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What to incorporate (Re: Options for IETF administrative restructuring)
Harald sed: scenarios C and D envision incorporating the *support function* for the IETF. The IETF would remain an undefined entity under these scenarios. I've had another suggestion that the IETF (the real technical process entity) should become a formally recognizable entity of some sort (possibly an unincorporated organization). But that's distinct from the idea of incorporating the support function, and is NOT described in the current document. imho both C D would be seen by most or the world as incorporating *the IETF* - if there is confusion within the IETF over the difference between incorporating the *support function* and incorporating the whole IETF the difference would be totally lost by non-IETFers (and most IETFers is my guess) - in any case, the target of any legal attack on the IETF would be the corporation with IETF in the name if one existed - about the only way I could see that there woudl not be confusion wiuld be to call the corporation The Corporation to Support Internet Standardization (TCTSIS or TCSIC) and not have the IETF name in it. Perceptions are always important. Under Scenario's A and B, likewise, the Internet Society probably gets to be a target. On the other hand, one benefit of incorporating an entity, such as an administrative support structure, is you can, to some extent, insulate yourself from frivolous attacks. You can also limit liability on non-frivolous attacks. Just as importantly, you have standing to enforce agreements, such as contracts with support organizations. Harald mentioned some other structures available. One possibility is the unincorporated association on which I've been doing some research. It will be in my next rev of the report, but people are always welcome to look at the work in progress: http://public.resource.org/adminrest/ -01 is the unpublished work in progress. Scenario E discusses the concept of the unincorporated association. Comments are welcome. I expect to put this next rev into the i-d queue on Monday. I still have some cleanup to do to incorporate comments by Bob Kahn and Brian Carpenter, and am trying to clean up the RFP stuff to make it a bit clearer. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Processing of Expired Internet-Drafts
Hi Fred - If I can have two separate files (a tombstone and a subsequent new file version) that have the same name, as described in the recent announcement, I am going to have to figure out a trigger that will tell me that I need to re-download the file. Incrementing the number also screws up a common operation for authors: is the internet-draft that I'm citing the current one? With the new algorithm, a search for a +1 version will yield a hit and I have to go look in that file. the context of the above. If the tombstone is literally as described, it would be far more space/search/etc efficient for us to have the tombstone consist of an added text line in a file indicating that the named draft expired on a certain date, and keep separate files for the active internet drafts. It seems to me that this makes it simpler to maintain a mirror and to find temporary documents. A tombstone jail containing that information would be preferable in my view to mixing them all together. Regards, Carl
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Hi - http://www.isc.org/products/BIND/delegation-only.html Carl I've just got to ask... I am seeing news that BIND WILL BE patched with this kind of support in it. Is this a sponsored patch, or is it just a random person posting a patch - that if applied would have this functionality Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Vixie Sent: Tuesday, September 16, 2003 7:33 PM To: [EMAIL PROTECTED] Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us] It is worth noting that if we are to pass judgement against Verisign there are at least half-dozen other TLDs that blazed the trail. We just overlooked them because of their size as compared to .NET and .COM. when people started beating on my phone ringer about wildcards yesterday evening, and screaming for patches to bind to somehow make it all better, i asked but other tld's do this, what's the big deal? as near as i can figure it, the problem is one of expectation. if someone signs up for .nu they know there'll be a wildcard there before they sign, and they can take appropriate precautions (like only using it for web or e-mail, and not naming hosts under that tld). the expectations for .com and .net to not have wildcards were all set many years ago, and it's the violation of those expectations that's got people angry enough to publish patchware about it. -- Paul Vixie
i-d's in rfc2629 format
To build a collection (not an archive) of internet-drafts in RFC2629 format (which is Marshall Rose's format for writing documents in xml (which is a subset of sgml and a generalization of html)), I'd appreciate it if people who have such documents would send me mail. Regards, Carl Malamud Internet Multicasting Service
Re: Why XML is perferable: manipulating and presentation
I hated ITU, but because now I can get ITU documents freely, Well, I've never hated the ITU, though I'm not sure the feeling is mutual. I consider myself a long-term friend of this august organization and have even served in the voluntary Friends of the ITU Auxiliary Standards Corps Organization. If you register on the ITU site, you can get up to 3 documents free, but you may not redistribute those documents (except as printed copies within the physical confines of your premises). After your three free documents, you pay on a retail basis. This is certainly a step in the right direction, though I'd be happier with n=3000 than n=3. An interesting contrasting policy is the U.S. Patent Office where you can get many documents free, and then pay for the full images. However, once you've covered their "incremental costs", you are free to redistribute those documents at will. Of course, bulk access to the USPTO database is not yet available and it appears that this bulk service will be provided by outside parties. Even more interesting contrasts are the IETF and the U.S. SEC where you can obtain all documents for free and redistribute at will. I don't hate it any more. Hate is not very productive, though long-term bewilderment seems to be near universal in this case. Regards, Carl
