Re: individual submission Last Call -- default yes/no.
Dave, I think that the requirements for a successful last call depend on how much review and interest have been demonstrated before the last call. For example, I recently last called draft-housley-cms-fw-wrap. It received no last call comments. What should I do with the draft? Well, in that case, I knew the draft had been reviewed (and changed based on comments) by several people in the S/MIME and security community. I also knew there was work on implementations and specific customers who plan to use the standard if approved. In my judgement as an AD, that was sufficient to justify bringing the document to the IESG even given no support in last call. There might very well be cases wher I'd bring a document to last call wher I was skeptical of the utility of the standard. I'd actually suspect that other tools for judging sufficient support before bringing a document to last call might be better, but last call is certainly a tool for judging support. In such a case, I might conclude that no comments were insufficient support. In conclusion, it seems like the ADs sponsoring documents have significant latitude in this area and that is a reasonable way for things to work. The community can complain that a standard is useless during last call; you can even say things like I don't see the point; if others don't chime in and say they would use this, please do not publish. In addition, the community has multiple ways of giving feedback if they believe that there are systemic problems in the criteria ADs are using. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-phillips-langtags-08, process, sp ecifications,
Peter == Peter Constable [EMAIL PROTECTED] writes: From: Dave Crocker [EMAIL PROTECTED] It occurs to me that a Last Call for an independent submission has an Peter added requirement to satisfy, namely that the community supports adoption of Peter the work. We take a working group as a demonstration of community support. Peter You say the community, though surely a working group is Peter only representative of a community or a portion of the Peter community. No. The entire community reviews the chartering of the working group. It's sort of complicated; community consensus does not appear to be required by 3418 in order to form a working group, although I would expect someone to appeal if a WG was formed and there was a rough consensus against the formation of that group. I do agree that individual submission last calls have greater latitude than WG last calls. I think that Even though the WG supports this, the IETF does not and thus we will not publish, is a valid outcome of an IETF-wide last call. IN practice it's harder to get that result than The IETF does not support this individual submission; we will not publish. Speaking only to general process and not to the issue at hand. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #770 Compensation for IAOC members
Sam == Sam Hartman [EMAIL PROTECTED] writes: Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald I think this line of thought has died down without any Harald great disagreement the consensus seems to be that the Harald following sentence: Harald The IAOC members shall not receive any compensation (apart Harald from exceptional reimbursement of expenses) for their Harald services as members of the IAOC. Harald belongs in the document. I think that placing it at the Harald end of 4.0 makes for the most reasonable placement Sam I don't think it belongs; I think ekr made a compelling Sam argument that this is a matter of policy not BCP. OK, too many things conflated. I agree saying that IAOC members should not get paid for time is appropriate BCP material. I missed all the wordsmithing that lead to the current text, but it looks like there were a fair number of messages. I won't pretend to be able to do better and since we need to say something we should say this. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
Wijnen, == Wijnen, Bert (Bert) [EMAIL PROTECTED] writes: Wijnen, The current text in section 3, 1st para states Wijnen, The IAOC consists of volunteers, Wijnen, does that not say enough? I think it does. I haven't seen an argument for why more text is needed in the BCP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-phillips-langtags-08, process, specifications, and extensions
Christian == Christian Huitema [EMAIL PROTECTED] writes: Christian Could you please pursue this rather technical Christian discussion on a specialized list, rather than the main Christian IETF list? There is sort of this problem that most of this traffic is last call comments on a document. Our procedures require that last call comments be sent to ietf@ietf.org or [EMAIL PROTECTED] iesg@ietf.org is not a public list; so if you want to make a last call comment that is visible to the world, not just the IESG, you do need to copy [EMAIL PROTECTED] That said, I think this discussion could benefit from discussion on the ietf-languages lists with agreed summaries at the end of the last call period. Sam, speaking as an individual. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: BCP -03: Compensation for IAOC members
Soininen == Soininen Jonne (Nokia-NET/Helsinki) [EMAIL PROTECTED] writes: Soininen x.x IAOC members compensation for labor, travel, and Soininen other costs Soininen The IAOC membership is considered voluntary. Hence, the Soininen costs sustained by the members to participate in the Soininen IAOC are not be reimbursed by the IASA or the Soininen ISOC. These costs include but are not limited to time Soininen used to perform duties of IAOC, travel to face-to-face Soininen meetings and accommodation during the meetings, and Soininen long-distance calls to IAOC teleconferences. I don't know about IAB calls, but with some exceptions IESG members do not pay to participate in the telechats. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #718 Transparency - reports on decisions
Brian == Brian E Carpenter [EMAIL PROTECTED] writes: Brian According to Merriam-Webster online: Main Entry: 2 minute Brian Function: transitive verb Inflected Form(s): min?ut?ed; Brian min?ut?ing : to make notes or a brief summary of Brian Brian Brian Sam Hartman wrote: Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald I suggest resolving this by adding the following text to Harald section 3.4 IAOC decision making, after the first Harald paragraph: All IAOC decisions are minuted. Minutes are Harald published regularly. I like the intent but don't like the word minuted. How about all IAOC decisions are recorded in the minutes of the IAOC. These minutes are published regularly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf I was complaining about style, not grammar. I'd argue that the verb form of minute has low familiarity compared to the plural noun form. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: #720 and #725 - Appeals and IAD autonomy
John == John Leslie [EMAIL PROTECTED] writes: JohnThe whole idea here, I thought, was to set up a support John structure which would just work -- so that it could be John invisible to the IESG and never need to be discussed by John that group. (The problem, I thought, was that shortcomings John of the current Secretariat were entirely too visible; and John the IESG was spinning its wheels discussing them.) No, the secretariat function will and should not be invisible to the IETF. The IESG and IAB are likely to be in the best position to set priorities for the clerk function. The IESG is probably the body that would make a decision if people felt that a particular meeting location did not meet our openness requirements. The IESG is involved in approving a lot of scheduling requests. However the IESG and IAB are only one of the customers of the administrative function. Today if the IESG asks for something there's not a good way to know if the request is reasonable nor how it is prioritized. Understandably, Foretec's priorities are not quite the same as the IETF's priorities.They are a for-profit corporation accountable to their shareholders. To the extent that they do what the IETF wants, it is because they choose to do so. factors like good will, demonstrating to other potential customers that they do a good job and just wanting to be helpful are probably all important. One goal of the IASA is to bring this accountability into the IETF. The IASA needs to balance priorities coming in from the IAB and IESG against other needs and against available money.The IESG is expected to continue discussing secretariat functions although we hope the spinning the wheels (to the extent that it does happen--I don't know yet how much that is)will stop. 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. JohnLet's review what John Klensin asked for: * the IETF John has got to keep its hands off the day-to-day decisions, John even when they seem wrong I don't strictly disagree with this although I'd prefer something less restrictive. The structure should reasonably represent the costs of reviewing decisions so that decisions are not reviewed more frequently than is appropriate. Some may argue that this goal is difficult to achieve and that simply never reviewing day-to-day decisions is a better approach. John * the IESG and IAB need to be John prohibited structurally from micromanaging, or managing at John all, beyond the degree that the IAOC wants to permit. John They supply input, they make requests, but decisions rest John on the IAOC side of the wall and stay there, with the only John _real_ recourse being to fire the IAOC It all depends on what you mean here by managing. The BCP explicitly calls out the IESG and IAB as important customers of the IASA--or did at one point. If you are a services organization you certainly should not be invisible to your important customers. It also seems like at least in practice your important customers will be able to create significant pressure to meet their priorities or to explain why this cannot be done in the money available. On paper, though, I agree that the decision rests with the IASA. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus? #718 Transparency - reports on decisions
Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald I suggest resolving this by adding the following text to Harald section 3.4 IAOC decision making, after the first Harald paragraph: Harald All IAOC decisions are minuted. Minutes are published Harald regularly. I like the intent but don't like the word minuted. How about all IAOC decisions are recorded in the minutes of the IAOC. These minutes are published regularly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: #720 and #725 - Appeals and IAD autonomy
John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 23 December, 2004 09:42 -0800 Carl Malamud John [EMAIL PROTECTED] wrote: 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 No, my concern is that John (i) the IESG, or the IESG's leadership, is likely to John micromanage because it has tended to micromanage, or try to John do so, many of the things it has touched in the last several John years -- the secretariat, the content of various documents John down to the editorial level, the RFC Editor, and so on (some John of that has gotten better in recent months or years, but John that isn't the point). Even you have made the claim that John they (for some instance of they) have tried to micromanage John you in terms of the contents of your various reports and John recommendations. And the discussion of why the IETF and IAB John Chairs had to be on the IAOC had, to me, a strong ring of John so we can make sure that administrative entity does exactly John what we want, which is close to an operational definition John of intended micromanagement. So that one isn't a corner John case, it is a simple extrapolation from behavior that has John been observed in the community (and commented upon in the John Problem Statement work, which makes it feel like I'm not John alone in those impressions). Micro-management is not the same as management. I actually think the IESG and IAB have done a good job of stepping in, applying management and solving some real problems over the years. I realize that I'm now part of the IESG and thus part of the organization that you believe is doing too much micro-management. However I haven't been involved in many of the past decisions and so I think that this response is at least mostly untainted by my involvement in the IESG.p So, I do see the IESG and IAB continuing to try and set priorities for the parts of the secretariat that influence the standards process. Clearly these priorities will need to be evaluated in the entire budget context by the IASA just as they are now evaluated by Fortec. I'm not sure what specific issues you believe are micro-management. However I contend that this BCP is not the right forum for these concerns to be addressed. If you have concerns about how the IAB and IESG are conducting themselves, there are several approaches you could take. First, you can provide input to the IESG and IAB about how they have handled specific issues and how they are handling issues before them. In cases where you believe it is necessary to do so, you can even appeal decisions. You can also provide feedback to the nomcom if you believe that a different set of qualifications or outlook is required for IESG and IAB members. --Sam, speaking only for myself ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: #720 and #725 - Appeals and IAD autonomy
I think your proposed three changes are a significant improvement over the current text. As I've said, I am willing to live with the current text but do not consider it ideal. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Old-standards] Re: [newtrk] List of Old Standards to be retired
John == John C Klensin [EMAIL PROTECTED] writes: John Harald, John Sorry, but I've got a procedural problem with this. I-Ds John can't obsolete anything, even I-Ds approved by the IESG. John While fiddle with the RFC Editor note in the John announcement... may be the usual reason for delay, we all John know that documents sometimes change significantly between John the last-published I-D and actual RFC publication. In John theory, the announcement could be posted, the IDR WG John membership could take a look at it and conclude the AD's RFC John Editor note does not reflect WG consensus, and an appeal of John the announcement could be filed. As far as I know, that has John never happened, but the procedures clearly permit it and I John can think of a case or two when maybe it should have. While John we have safeguards to prevent it, it is even possible that a John document inadvertently would change enough during the RFC John editing process that the WG would no longer believe it was John an appropriate replacement for the earlier document. I don't think everyone believes the procedures work this way. A while back, there was a discussion on wgchairs about when the timer started for a standard moving to draft standard. My interpretation of that discussion was that it was the protocol action message that established a new standard, not the publication of the RFC. Personally I don't care how it works. I see both the points you raise and the arguments in favor of the wgchairs discussion. To me, either way of doing things would be valid. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
William == William Allen Simpson [EMAIL PROTECTED] writes: William John C Klensin wrote: Then these need the bad designation, not just the not really interesting any more one. And that, presumably, requires a 1828/1829 considered harmful document, or at least a paragraph and a place to put it. William Well, gosh and golly gee, I wrote an ISAKMP considered William harmful about 6 years ago, and the IESG -- for the first William time in its history -- ordered it removed from the William internet-drafts repository (saying the IETF wouldn't William publish anything critical of the IETF process). I wasn't following things closely enough at the time to have an opinion on what happened then. However I do have an opinion on the current process. Things change and sometimes improve. I'd like to think the IETF and the security area in particular are more open to criticism and to the realization that we may be wrong. I believe I have some evidence for this belief. There might be some reasons why it would be appropriate to remove a document from the ID repository--most of the ons I can think of have to do with copyright issues--but I don't think a document being critical of the IETF, its processes or technology would be such a justification today. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
Bruce == Bruce Lilly [EMAIL PROTECTED] writes: Bruce If there really are only 24 items of less than 11 octets Bruce each, a trivial solution is to simply list them (with the Bruce usual ABNF syntax) as literal strings. That should take no Bruce more than a half-dozen lines. Perhaps. I actually find a lot of ABNF specs are not as clear as they could be to humans because they are trying to describe the valid inputs as strictly as possible. In many cases I think the spec would be more clear if the ABNF were relaxed and other constraints were expressed at appropriate levels. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
Simon == Simon Josefsson [EMAIL PROTECTED] writes: Simon In general, I support your goal of permitting free software Simon to fully use IETF standards. A few specific comments Simon below, which should be taken as encouragement to continue Simon and refine the terms, not criticism against the whole Simon approach. Simon Lawrence Rosen [EMAIL PROTECTED] writes: 1. Everyone is free to copy and distribute the official specification for an open standard under an open source license. Simon I would include modify in this clause, or clarify exactly Simon which license you are talking about (e.g., GNU Free Simon Documentation License). We've been over this before. In my mind, there is not a consensus to revise this part of the IETF IPR policy at this time. I'm not the chair of the IPR working group; this is just my opinion. However by conflating issues where you could get support with issues where you cannot get support you frustrate everyone and cause a lot of us to want to ignore you. If the open source community cannot work within the IETF process in a spirit of compromise and consensus building then that community will not make significant progress within the IETF process. Simon, you've identified a real issue the free software community has using our standards. If you do the leg work or find others who are interested in doing the leg work, you have a good chance at getting the problem you've identified fixed. However if you tie fixing that problem to other much more controversial issues, I doubt you will succeed. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-iasa-bcp-02: section 7 - Removability - BCP
Scott == Scott Bradner [EMAIL PROTECTED] writes: Scott open from last version I'd change BCP publication to using its normal consensus processes (BCP is no magic term and may not survive the newtrk process) Scott I did not see anyone speak up to support the use of the Scott term BCP yet the term (the meaning of which may change in Scott the future) is still used I like the term BCP in this iinstance. I think it is more clear than Scott's text. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
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. The text you are objecting to is added specifically because of IETF concerns that individuals and smaller donors cannot ear-mark donations for the IETF under the current ISOC process. If that is going to continue to be true it is worth calling out to the IETF community and confirming they can live with that reality. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP -02 Designated Donations - section 5.3
JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes: JFC Tax aspects on donations will, most probaly in many JFC countries, call for donations to a legally incorporated JFC entity. What is the IETF legal entity I am to write on the JFC check and then claim for resulting tax benefits for JFC supporting research. No tax controller will buy that ISOC is JFC an RD lab. jfc The IETF is an engineering organization, not a research lab. Most of the funding will not go to activities that would traditionally be described as research. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
Bruce == Bruce Lilly [EMAIL PROTECTED] writes: Date: Sat, 11 Dec 2004 12:14:42 -0800 From: Randy Presuhn [EMAIL PROTECTED] Subject: Re: Ietf-languages Digest, Vol 24, Issue 5 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Hi - From: Bruce Lilly [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, December 10, 2004 4:54 PM Subject: Re: Ietf-languages Digest, Vol 24, Issue 5 ... Eliminating bilingual descriptions for the language, country (and UN region) codes leaves implementors in a quandary. ... Huh? These are language TAGS. If, for some reason, some implementor thought it made sense to display one of these in a localized form (rather than just using them to determine what locale, etc. should be used in rendering some text) there's no requirement that the English-language country names that appear in the registration be used. Bruce That's not the point. The point is that under RFC 3066, the Bruce bilingual ISO language and country code lists are Bruce considered definitive. An implementor can (and has) Bruce therefore use those lists for (e.g.) providing users with Bruce menus (in either language) from which a language or country Bruce code may be selected. By declaring the ISO lists no longer Bruce definitive, and by providing only English descriptions of Bruce the codes in the proposed revised registry which would be Bruce used instead of the ISO lists, the draft proposal deprives Bruce implementors of being able to provide that functionality Bruce (viz. an official description in French of codes). Programming lore has the rule of zero, one or infinity; it goes by many other names but the concept is in part that by the time you need more than one of something, you'll probably need a lot of that thing. Language descriptions seem to fit this rule fairly well. By the time we need to support multilingual language descriptions, we'll need more than just English and French. That means implementers today already have to deal with the fact that they only have some of the language descriptions they need from definitive standards. They will already have to get descriptions for other languages. Since they are already using non-definitive language descriptions, implementers can feel free to take the French descriptions from the ISO standard for the many cases where the IANA registry and ISO standard overlap. Why is two definitive languages better than one definitive language and one set of descriptions from an ISO standard? --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: bcp-02: Section 3.4
I've been thinknig more about the issue of the appeal process. Here are some of the questions I have considered and the answers I've found. First, can I provide something I'd like better than the current text? The obvious candidate is the text in draft-ietf-iasa-bcp-00. This would be problematic for two reasons. First, I don't think we could get a consensus in support of that text. Second, several people pointed out a real potential for abuse of that process. The concern that the IASA would not be able to do its job because of various appeals is serious. Harald also pointed out that designing appeals processes are hard; we should not do so if we can avoid it. I do not believe I'm capable of designing a process that is not subject to abuse and that meets my concerns in the time available. Is the appeals process in iasa-bcp-02 a regression over the status quo? Currently there is no formal process for the IETF to appeal a decision of the secretary. In practice CNRI responds to concerns raised by the IETF chair. I'm aware of nothing that requires them to do so. As such, this process does not appear to be a regression. An important side note is that without an appeals process we seem to be doing moderately OK; it is likely that this process will not often be used. Do we have recourse if we find the appeals process in the BCP is inadequate? As others have pointed out we do have the option of a recall of some or all IAOC members. If that were all the choice we had, I would consider the current text unacceptable. However we also have the option of creating or revising a new appeals procedure. I'd hate to find ourselves in the position of doing that in response to a specific issue, but it is an option we have and an option appropriate to use if circumstances justify its use. Relying on this option is dangerous: if we feel that we are not in a position to design an appeal process now, how will we feel when faced with the urgency and division of a pressing process failure? In conclusion, I do not like the current text. However it seems like the best option available in the time we have. It is something I can live with. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
bcp-02: Section 3.4
I'm not very comfortable with the appeal text in section 3.4. There isn't a way to overturn decisions and there is no way to appeal decisions because the wrong decision was made. I understand why the current text is there. I understand there are significant concerns about having either of the things I'd like to see in an appeal system. I will try and think of constructive ways of getting better appealability without destroying the IASA's ability to do its job. I'm also not sure how uncomfortable I am with the current text. I know I don't like it, but it's hard to tell how strong that feeling is. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
Simon == Simon Josefsson [EMAIL PROTECTED] writes: Simon [EMAIL PROTECTED] (scott bradner) writes: For IDN, I want to be able to extract the tables from RFC 3454 and use them in my implementation. For Kerberos, I want to be able to use the ASN.1 schema in my implementation, and copy the terminology section into my manual. For SASL, I want to incorporate portions of the introduction section from the RFC into my manual, to make sure some terminology is explained correctly. For GSS-API, I want to be able to copy the C header file with function prototypes into my implementation. just so there is no misunderstanding - the intent of RFC 3668 was to permit such extractions and there was (and is) no desire to restrict such extractions I, as editor, state publicly that I think that RFC 3667 permits such extractions, we (or maybe I) may have not made that clear enough in RFC 3667, but I think that RFC 3667 supports these uses Simon I have received preliminary feedback from IPR specialists Simon that seem to indicate to me that neither the old RFC Simon copying conditions, nor the new copying conditions in RFC Simon 3667, would permit all of the above extractions into free Simon software. Simon I am working on getting them to explain their reasoning on Simon the Free Software Foundation's web pages (presumably at Simon [1]), which I believe would be useful input for the IPR Simon working group, but the process has been slow. I hope I'm Simon not putting words in their mouth by stating that my Simon interpretation of what they said is that there is a Simon problem. Simon Do the IETF care about free software enough to work on Simon modifying the copying conditions of future RFCs? Speaking as an individual, *not* as an AD, I'd love to see the free software community get together and give input to the IETF (possibly in the form of an informational RFC) on the following issues: 1) Extracting tables and code from IETF standards for use in free/open-source software. 2) What patent holders who would like to license software should do if they want to create a license that open-source/free software authors can use when licensing technology in Internet standards. Such input should explain what the requirements are and should give both legal and practical reasoning to justify them. Such input should avoid trying to criticize or demand changes in the IETF, but instead should focus on what the IETF would need to do if we need to make parts of our RFCs extractable or what patent holders would need to do to make licenses useful to the free software community. I would strongly recommend avoiding discussion of the general patent policies of the IETF; arguments that the IETF should not use patented technology will only serve to annoy people who might otherwise listen to what you have to say. I'd recommend that any such input accurately represent at least the following parties positions': 1) The Free Software Foundation 2) The Open Source Initiative 3) The Debian Project I believe all three of these parties have slightly incompatible views on the issues in question. It would be very frustrating to consider such input only to discover that some segment of the open source community still felt we had not addressed their concerns even though the input was represented as complete. If you do get free software people to talk to the IETF about IPR, please find people who can work well in the consensus process. People who are good at explaining and understanding are better than people who have firm convictions and are good at arguing. However when explaining the needs of external communities participants would need to actually accurately represent these needs. It would be unfortunate if we came to a compromise that was acceptable to everyone involved in the consensus process only to find that it was unacceptable to the external community. Good luck, --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus(2)? IPR rights and all that
Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald6. The IETF, through the IASA, shall have a perpetual Harald right to use, display, distribute, reproduce, modify and Harald create derivatives of all data created in support of IETF Harald activities. Harald (Jorge liked perpetual better than irrevocable Harald permanent - the stuff after to is a well known legal Harald incantation). This works for me provided that the legalese gives us the right to sublicense these rights to others. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Consensus(2)? IPR rights and all that
Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald --On tirsdag, desember 07, 2004 04:49:36 -0500 Sam Hartman Harald [EMAIL PROTECTED] wrote: Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald 6. The IETF, through the IASA, shall have a perpetual Harald right to use, display, distribute, reproduce, modify and Harald create derivatives of all data created in support of IETF Harald activities. Harald (Jorge liked perpetual better than irrevocable Harald permanent - the stuff after to is a well known legal Harald incantation). This works for me provided that the legalese gives us the right to sublicense these rights to others. Harald That's more than we currently ask people to assign to the Harald IETF when making submissions to the IETF (RFC 3667) - Harald there, we ask only for permission to use it within the Harald IETF process (which may mean some sublicensing, and may Harald not). Not sure what we should write here - I wouldn't want Harald to write something here that would require reopening RFC Harald 3667 for consistency. well, I do happen to think 3667 is broken, but agree with you that we do not want to open that can of worms at this time. However if we change contractors, we need to have the necessary rights to give the new contractor the rights to use our data. I believe that is an absolute requirement. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5b (appealability)
avri == avri [EMAIL PROTECTED] writes: avri OK, I am open to the idea. And I suppose that the current avri appeal mechanisms would allow it. avri But in that case I do have a problem with making the barrier avri higher for appeals originating from a non IOAC member. avri While I can see arguments for not removing an IAOC's avri member's right of appeal, I don't see any arguments that avri should give them any greater right of appeal. I.e. I would avri have difficulty supporting a mechanism that weighed 1 IAOC avri member versus 10 non members as suggested in your original avri message. The reason you want to require say 10 signatures is because you want to avoid a denial of service attack on the process. You don't want someone who lost a contract appealing unless there were significant process irregularities. My assumption is that if the members of the IAOC want to gum up the works with useless appeals, you might as well get the recall petition started. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: section 3.5
Scott == Scott Bradner [EMAIL PROTECTED] writes: Scott but as I said before - I expect we will be close to failure Scott if the IAD proceeds on the basis of a close vote in the Scott IAOC. I'd rather that mininum vote required to proceed (in Scott those cases where a vote is needed because of disagreement) Scott be a majority plus one I disagree. One area consensus-based decision making deals very poorly with is the ability to make a decision between two close but both quite acceptable options. For example let's say the IAOC is deciding between two possible contracts and both contracts are acceptable to all the members. Some prefer one; some prefer the other. This actually comes up reasonably often and voting with majority wins is a fine solution. Presumably the IAOC will have flexibility to define super-majority requirements for classes of decisions that they believe might require these decisions. Also, if an unacceptable decision is made, it can be appealed. I think saying less is better than more in this instance and thus support the current text. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: section 5.3 B
Scott == Scott Bradner [EMAIL PROTECTED] writes: Scott section 5.3 goes on to say Designated monetary donations Scott will be credited to the appropriate IASA account. Scott a left over reference to a seperate account To me this doesn't imply bank accounts; internal accounting that tracked IASA items separately would seem to fit this requirement. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Adminrest: IASA BCP: Separability
Margaret == Margaret Wasserman [EMAIL PROTECTED] writes: Margaret 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. Margaret This is interesting, because I had not assumed that Margaret there would be a separate MOU... I had sort of assumed this BCP would be the MOU to the extent that one existed. I don't object to other arrangements though. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
Michael == Michael StJohns [EMAIL PROTECTED] writes: Michael It seems to me that neither ID status nor RFC status are Michael appropriate for these documents. The ID series is, by Michael design, ephemeral and generally not citeable. The RFC Michael series is stable and citeable, but the lead time for Michael introducing an RFC is somewhat north of 30 days or more. Michael I hate to open Pandora's box, but what I think we need is Michael a citable, stable document series that has a production Michael lead time similar to that of the IDs. I would probably Michael limit this to the non-technical administrivia we've been Michael recently inundated with. Michael *sigh* Please provide some justification. You said that you needed these things but you didn't really say why. I also don't understand how this is any different than work that goes on in a lot of protocol working groups. I'm particularly confused about why we would have documents that we neither want to be long-lived but that we cannot be bothered to resubmit every six months. If we want the document to be long-lived, what is wrong with RFC publication? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Executive Director
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: AdminRest: IASA BCP: Finances and Accounting - principles
John == John C Klensin [EMAIL PROTECTED] writes: John Bert, _Far_ too much detail. See earlier note about the John bank account material. I suspect that I speak for many John members of the community when I say that I want to get this John admin stuff fixed, and fixed as quickly and efficiently as John possible, after which I Do Not want to have to revisit it at John regular intervals, through Last Calls or otherwise. So, what level of detail do you think is appropriate? Is the community still interested in guaranteeing that the IASA is reasonably seperable from ISOC if necessary? How much detail is needed to allow the community to evaluate whether the IASA will in fact be seperable? Is it sufficient to simply state seperability as a goal or do we want to deal with specific details like the bank account? Personally, I do believe that stating some details would help me evaluate whether IASA is seperable and would require the IETF's consent in order to change the details. I do think that requiring IASA keep separate bank accounts is probably desirable at the BCP level. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Issue: Budgeting process and financial oversight
Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald 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. Harald I think that is the right division of labour (the IASA Harald *does* the work, the IAOC *oversees* the work, and the Harald IAOC is *not* part of IASA). So any power that implies Harald *doing*, including chartering committes that help define Harald or refine the support for the IETF, should be given to the Harald IAD, not to the IAOC. Any committee that does *oversight* Harald (for instance an audit committee) should be chartered by Harald the IAOC. This makes sense to me. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Should IAB chair be a voting member of IAOC
Erik == Erik Huizer [EMAIL PROTECTED] writes: Erik My sense is that an IAB chair is probably very well informed Erik and will have very good insight into all the issues Erik surrounding the IASA. Therefore it makes sense to give the Erik IAB chair a vote. The reason it would not make sense to do so seems to be (as I understand it) that doing so might allow the IAB chair to focus less energy on the IASA and more on Internet architecture. In my mind the question boils down to are IAB chairs likely to want a vote? IF so, we should give it to them. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
Brian == Brian Rosen [EMAIL PROTECTED] writes: Brian You guys don't have a problem with the defensive Brian suspension/no first use clauses, do you? There is not consensus in the free software community on this issue. I believe the Open Source Initiative (opensource.org) is OK with such clauses. Debian (debian.org) is not although there are some of us within Debian who question this decision. I don't know what the FSF's stance is on this issue. This is one of the many reasons why I think the free software community needs to get together and decide what it wants *before* coming to the IETF. Again, I'm not proposing that the free software community can change the IETF's IPR policies We had that debate recently and it's clear there is not consensus to change it. I do think that some patent holders want to make their technology available to the free software community. I believe that if the free software community agreed on what it wanted, it would be reasonable for the IETF to pass that along to IPR holders as information to consider when drafting proposed licenses. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: isoc's skills
Dave == Dave Crocker [EMAIL PROTECTED] writes: Dave My focus is on knowing what the details of the jobs are that Dave we want done. Referring to the interface(s) is a convenient Dave technique for trying to surface those details. Dave Currently we do not have the details. What we are doing is Dave like buying a building or a vehicle before we really Dave understand what uses they are going to be put to. This Dave leads to thinking that those details are trivial. They Dave aren't. I think many of us agree with you that we do not know the details. I believe we also agree that we will eventually need to know the details. I don't seem to require the details you are asking for to feel like I'm making an informed decision between the two scenarios. I think thas' because I cannot imagine how the sorts of details you are talking about could influence my decision at this level. Could you perhaps come up with two possible parts of the answer for what we're trying to accomplish here that influence the decision between the two scenarios? If you could show one possible job we might want done that favors a corporation and another that favors working within the ISOC struture, you would go a long way to showing people that we need to discuss the kind of details you are asking for now instead of later. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
scott == scott bradner [EMAIL PROTECTED] writes: If you understand the open source position and disagree with it, then there's probably little more to say. scott If the position is that the open source community can take scott an IETF consensus-based standard, modify it and claim that scott the new version is the real standard then I do disagree - scott I think that standards must be developed and modified in scott open consensus-based processes, not by individuals or scott groups unrelated to the group that developed the standard. The open source community definitely wants to be able to guarantee to its users the ability to take text or code from an IETF standard and use that text or code in derivatives of that standard. Parts of the open source community want to be able to claim that that standard is the real unmodified thing. Other parts of the open source community would be happy changing the name of the work and clearly indicating what it is. Areas where a discussion might be useful would be to explain why the open source community wants to do this etc. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
scott == scott bradner [EMAIL PROTECTED] writes: scott seems to be a reliable way to ensure that there are scott multiple understandings of what the standard actually is - scott I find it hard to understand who that is good for Do you think that trying to describe a modified version of TCP without taking text from the original RFC is likely to lead to a better situation? Honestly I think the issue of whether derivative works can use text from the original is distinct from whether derivative works can be confused with the original. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
Eric == Eric S Raymond [EMAIL PROTECTED] writes: Eric You've had two direct warnings about this -- the ASF and Eric Debian open letters. They interpreted IETF's passivity on Eric the Sender-ID patent issue as damage and routed around it. Eric If the IETF doesn't get its act together, that *will* happen Eric again. The open-source community and its allies will have Eric no choice but to increasingly route around IETF, and IETF Eric will become increasingly irrelevant. I'm a bit confused here. As I understand things, Debian and ASF provided input to an IETF consensus call. They asked us not to approve a standard that depended on certain IPR. Based on that input and other input received by the working group, the chairs decided that they did not have consensus to advance a standard based on this IPR. I.E. The IETF did exactly what Debian and ASF asked us to do. That seems like a reasonable outcome under our process. It also seems directly consistent with what Debian and ASF asked the IETF to do. Could you help me understand your concern? --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: CRAMing for last call
Lyndon == Lyndon Nerenberg [EMAIL PROTECTED] writes: Lyndon Finally, we need to address the issue of the MD5 break. Lyndon I have held off from commenting on this issue until the Lyndon community has seen explicit evidence of the attack, and Lyndon the implications of it. At this point, I don't know if the Lyndon document deserves a writeup on the attack. Theory abounds, Lyndon but I haven't yet seen a practical attack that works in Lyndon the general case. We should at the least make mention of Lyndon what has been discussed, and point to the literature, but Lyndon I don't think the document deserves to discuss all the Lyndon possible attacks. This doesn't mean to discourage anyone Lyndon from contributing text to the Security Considerations Lyndon section (please do). The security area seems to believe that hmac-md5 is still OK, at least for now. Especially since cram-md5 does not require much structure for the challenge, we should discuss the issue in the security considerations section. Will you need agenda time at the next meeting? If so, can you give an estimate of how much and what we want to cover? Thanks, --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: My views on the Scenario O C
Bob == Bob Hinden [EMAIL PROTECTED] writes: Bob The ISOC is certainly not perfect and has had serious Bob problems in the past. These problems have been solved and as Bob far as I can tell the ISOC is working well. I would note Bob that the ISOC was initially set up by competent people with Bob the best of intentions, but things did not work out as Bob originally planned. Would you mind summarizing these problems for those of us who are relatively new to the process? Thanks, --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Scenario O Re: Upcoming: further thoughts on where from here
I'd like to express general support for scenario O. I probably will not have time to read the document in sufficient detail to agree with every point, but this looks like a good direction. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 62
Two things brought up in this thread disturb me. First, there seems to be the idea that we should be choosing where IETFs are held for political purposes--to make statements for or against certain governments. I'm not quite sure this was said or implied, but if it was, I'm made a bit uncomfortable by it. I certainly understand we should carefully consider situations that make people unable or unwilling to attend an IETF. Maximizing the number of active (and potentially active) participants who can make it to a meeting is a valid thing to consider. If the political policies of a country make it hard to get the people we need in that country then we should go there less frequently or not at all. Note that one way these policies can make it hard for us to get the people we need in a particular country is for these people to be unwilling to travel to that country. However in similar situations (not all of them within the IETF context) I've seen the desire to avoid a particular country go beyond what is justified by a desire to make the conference accessible. In some cases it seemed to venture into the realm of political statement. The conference seemed to want to say that they were taking a stand against the policies of a country. That is dangerous: getting involved in politics may compromise our ability to construct the best Internet we can. There may be some cases where we must get involved in politics; I'm skeptical that any involve conference venue selection. Even worse, it sometimes seems like the desire is to go beyond a statement and actually punish countries by not going that. That's just stupid; we end up punishing our own attendees from those countries, not the countries themselves. Again, I'm not sure I see this problem in this thread. It's not entirely clear what peoples' motivations are. I know that I feel more comfortable with the outcomes of discussions based on fair distribution of travel and convenience of participants than I do with the outcomes of discussions based on fingerprinting, rules and who is involved in a particular country's decision making process. This is true even when the discussions produce identical results; the process matters. Secondly, I'm concerned that people are proposing optimizing for pleasant climate and good vacation spots. I come to the IETF to get work done; I'd rather be at meetings where the other participants have the same goal. We should be somewhat careful of optimizing for enjoyable location. I'd rather see us optimize for who can attend and cost. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Options for IETF administrative restructuring
Hi. First I'd like to start off by saying that I think Carl's document is a very good start for discussing these options. I support the recommendations made in section 3. I believe they are well justified and would be a great step in the right direction. Section 3 talks about clarifying the intellectual property ownership of the IETF's IP. One important area of IP ownership was not covered: the tools developed to perform the clerk function. I believe that the IETF should work to own these tools for several reasons. It will facilitate easier transitions from one vendor to another. It will facilitate accepting volunteer improvements to these tools. Finally, the IETF could make these tools available to other groups trying to solve similar problems. I suspect that these benefits would justify any additional expense involved in owning these tools rather than treating the clerk function purely as a service. Perhaps I'm wrong; I certainly feel that the IETF should explicitly understand what value it is getting if it decides to allow someone else to own tools developed to solve IETF needs. I do not think that recommendation 7 in scenario B is a good idea. I believe that plenary time is full enough without crowding it more. I'm concerned that the document doesn't really motivate Scenario C or D. It does describe them and it does list some of the disadvantages. However it doesn't really explain why they are on the table at all. I think they should be on the table; people have made arguments to that effect here. However the document doesn't do a sufficiently good job of capturing these arguments to explain why these options are sufficiently credible as to be worth examining. Where did the idea of forming a corporation come from; why would we want to do it again? Thanks for your consideration, --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Options for IETF administrative restructuring
Aaron == Aaron Falk [EMAIL PROTECTED] writes: Aaron On Sep 5, 2004, at 4:15 PM, Sam Hartman wrote: I do not think that recommendation 7 in scenario B is a good idea. I believe that plenary time is full enough without crowding it more. Aaron What about a 'business meeting' that is scheduled in wg Aaron slot or even on Sunday? If needed, this would be fine. I'm not convinced that open f2f time will be needed. However I think there is a simple test for whether the time is needed: can we come up with an agenda that fills a slot and meaningfully involves the community? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Proposed Standard and Perfection
Eliot == Eliot Lear [EMAIL PROTECTED] writes: Eliot Sam, As the person who most recently complained, let me Eliot elaborate on my comments. The problem I believe we all are Eliot facing is that the distinction between Proposed, Draft, and Eliot Internet Standard has been lost. Eliot I agree with you 100% that... The point of proposed standard is to throw things out there and get implementation experience. Eliot But when it comes to... If specs are unclear, then we're not going to get implementation experience; we are going to waste time. Eliot We disagree (slightly). In my experience one needs to Eliot actually get the implementation experience to recognize Eliot when things are unclear. And my understanding is that this Eliot is precisely why we have PS and DS. I've had a lot of experience with a rather unclear spec with some significant problems that managed to make its way to proposed standard: For the past 10 years I have been dealing with problems in Kerberos (RFC 1510). This leads me to believe very strongly that catching problems before documents reach PS is worth a fairly high price in time. Eliot We come to different conclusions here. My conclusion is Eliot that no standard should remain at proposed for more than 2 Eliot years unless it's revised. Either it goes up, it goes Eliot away, or it gets revised and goes around again. It's been under revision for all of that time. Eliot Your fundamental problem with RFC 1510 is that it is too Eliot painful for people to go and fix the text. And that's a Eliot problem that should be addressed as well. nWell it certainly has been painful but because of a number of false steps and to some extent because of WG management issues, it has taken 10 years, not 2 years to revise RFC 1510. we might have gotten it down to 7 or 8 by fixing the WG management. Eliot Thus, let the IESG have a bias towards approval for PS, and Eliot let implementation experience guide them on DS and full Eliot standard. But set a clock. It's in significant part because I think a lot of things may take more than 2 years to revise understand and fix that I believe this approach is wrong.
Re: Visa for South Korea
Ken == Ken Hornstein [EMAIL PROTECTED] writes: What I'm really looking for is some form of official government communication on the subject (unless of course the hosts are the ones who are manning the passport control desks at the airport). So call the nearest Korean consulate/embassy. Answering this kind of question is part of their job. Ken I actually already had put a call in to them; the relevant Ken person was out of the office, but I left a message. We'll Ken see what they say. I did as well and here is what I got. The phone was answered. I asked to speak to someone about Visa information. I was transferred to someone who answered in Korean; I did not understand the greeting. Hi. I'm an American citizen traveling to Seoul in late February to attend a meeting of a professional society. Do I need a visa? She asked again for my citizenship and then said that I did not need a visa. I chose to describe IETF as a professional society because saying standards development organization when referring to something non-ISO-based might confuse a government official. Similarly, I was concerned that conference might map to academic conference. I'd be interested in answers people get from other consulate/embassy staff both from locations other than Boston and with different phrasings of the question.
