Re: What review is required for IETF Consensus?
Harald and all, I Guess that a IETF consensus really means whatever you Harald says it means much like what consensus meant while you were Chair of the DNSO GA. But to be honest, no consensus can be determined unless it is measured, which means a VOTE must be held amongst IETF participants. Perish the thought, eh Harald?! ;) Harald Tveit Alvestrand wrote: Thread B from my previous message. this is being CCed to the POISED list, for reasons that may be obvious after reading the message; for POISED subscribers - this is followup to an IETF list thread. Question: What review process must the IESG take before taking the action to block or allow publication of such an internet-draft (ie what does IETF Consensus mean)? This is not written in RFC 2434. Some tactics that have been used in the past to gather information for the IESG's decision include: - It's obviously OK. Approved WG document, or competently written documentation from subject matter experts, reviewed by people with competence on the specific registry. The IESG looks at it and thinks that it's obvioiusly right. Example: application/ogg, documented in draft-walleij-ogg-mediatype. - Subject matter expert group review. For instance, posting to the DHC WG asking for opinions on a DHCP extension. WG chairs' feedback will carry a lot of weight. - IETF Last Call for Informational/Experimental, with the IESG evaluating the feedback. In all cases, the IESG has to evaluate; there's no other established body to do it. The buck stops here. Among the cases to consider: - Everyone approves. Go for it. - Nobody cares. No comments; the IESG will usually decide that nobody saw any looming danger to the Internet, and allow the registration. - Serious objections. The comments clearly indicate that the registration would be harmful to the Internet (and how), and the IESG agrees with that evaluation. The IESG will refuse. - Incompetent or incomplete document. The IESG will usually object to this on its own - without documentation clear enough to determine whether this is OK or harmful, it would be remiss of the IESG to let the document go forward even to an IETF Last Call. We can't claim IETF consensus on something we can't understand. - Dissension within the IETF. Like in the case of a WG, the IESG has to evaluate the arguments on their merits; obviously the proposers think that the registration should be allowed, and opposition without a rational basis should no more be allowed to block this registration than it should be allowed to block WG progress. But as the saying goes - this is why you get the big bucks. Among the things to consider here is that the determination must be made in a timely fashion - sometimes there are reasons why letting debate rage for another 6 months doesn't seem like an attractive option. Questions for the audience: - should this description, or something like it, go into draft-iesg-procedures? - are there guidelines that the IESG should use when trying to determine the right outcome in the dissension case? - does this debate belong on the POISED list, together with the discussion of the IESG charter and the IESG procedures? Thoughts? Harald Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail [EMAIL PROTECTED] Contact Number: 214-244-4827 or 214-244-3801
The IETF_Censored mailing list
The IETF_Censored mailing list At times, the IETF list is subject to debates that have little to do with the purposes for which the IETF list was created. Some people would appreciate a quieter forum for the relevant debates that take place, but the IETF's policy of openness has so far prevented the IETF from imposing any censorship policy on the [EMAIL PROTECTED] list. To give people an alternative, there is a list called [EMAIL PROTECTED]. This list is a sublist (that is, it gets the same messages as) the open IETF discussion list. However, this list will not forward all messages; in particular, the filters have been set so that persons and discussions that are, in the view of Raffaele D'Albenzio, irrelevant to the IETF list are not forwarded. Because this filter is automated, the criteria include: * Well known troublemakers * Well known crosspostings * Subjects that have led to recent non-conclusive exchanges * Some ways to say unsubscribe * Some out-of-office-reply messages To join the list, send the word subscribe in the BODY of a message to [EMAIL PROTECTED] (the URL here is an RFC 2368 mailto URL that does the Right Thing). To unsubscribe, send the word unsubscribe in the BODY of a message to [EMAIL PROTECTED] Do not send to the list - your message will be filtered! (members of the main IETF list itself must follow instructions for that list, of course. You are only a member of ietf_censored if there is a comment on the bottom of your IETF list mail saying that the message has been sent through the ietf_censored list.) For fun, there is a special list for the rejected messages: [EMAIL PROTECTED] - subscribe in the same fashion, by mail to [EMAIL PROTECTED] By public request, the current set of filters are listed at http://vesuvio.ipv6.tilab.com/cgi-bin/ietf_censored-filters This page is http://carmen.ipv6.cselt.it/ietf_censored.html, and is posted monthly in text form to [EMAIL PROTECTED] _ Raffaele D'Albenzio [EMAIL PROTECTED]
Re: What review is required for IETF Consensus?
I must admit to some confusion about what Harald is asking for. The context here is discussion of RFC 2434 Guidelines for Writing an IANA Considerations Section (BCP 26). We're discussing example policies for IANA assignments. Specifically there is: IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). which requires publication of an RFC, and IESG Approval - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis). I think Harald is asking for comments on this. Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: Question: What review process must the IESG take before taking the action to block or allow publication of such an internet-draft (ie what does IETF Consensus mean)? This is not written in RFC 2434. I read this section of RFC 2434 as an escape hatch, not as a regular process. Before I can intelligently discuss the process for IESG Approval, I need some justification of why this option is used at all. It strikes me as decidedly unwise to make a permanent IANA assignment based upon an Internet Draft (which by definition expires in six months). Some tactics that have been used in the past to gather information for the IESG's decision include: - It's obviously OK. Approved WG document, or competently written documentation from subject matter experts, reviewed by people with competence on the specific registry. The IESG looks at it and thinks that it's obvioiusly right. Example: application/ogg, documented in draft-walleij-ogg-mediatype. Well, immediately we are struck with the question, _which_ draft-walleij-ogg-mediatype. I believe draft-walleij-ogg-mediatype.08 is current. Granted, I have no reason to believe the IANA assignment has changed or will change; and the actual registration is minimal: To: [EMAIL PROTECTED] Subject: Registration of MIME media type application/ogg MIME media type name: application MIME subtype name: ogg Required parameters: none Optional parameters: none Encoding Considerations: ... Security Considerations: ... Interoperability considerations: .. Published specification: See [1] where [1] is: [1] Pfeiffer, S., The Ogg encapsulation format version 0, Internet-Draft , November 2002. There's the problem: We've got an unquestionably useful format depending on a document which will expire in May. IMHO, this richly deserves an RFC (which doesn't expire). - Subject matter expert group review. For instance, posting to the DHC WG asking for opinions on a DHCP extension. WG chairs' feedback will carry a lot of weight. This is a limited case, where the appropriate WG is still active. Clearly the WG Chair is the appropriate judge of WG consensus. But the documentation is always in danger of being too sparse... - IETF Last Call for Informational/Experimental, with the IESG evaluating the feedback. Isn't that an RFC? In all cases, the IESG has to evaluate; there's no other established body to do it. The buck stops here. Among the cases to consider: - Everyone approves. Go for it. - Nobody cares. No comments; the IESG will usually decide that nobody saw any looming danger to the Internet, and allow the registration. So long as there's no imminent danger of exhaustion of the name space, and the documentation is adequate, I agree. - Serious objections. The comments clearly indicate that the registration would be harmful to the Internet (and how), and the IESG agrees with that evaluation. The IESG will refuse. - Incompetent or incomplete document. The IESG will usually object to this on its own - without documentation clear enough to determine whether this is OK or harmful, it would be remiss of the IESG to let the document go forward even to an IETF Last Call. We can't claim IETF consensus on something we can't understand. Technically, we're not talking about IETF consensus ... However, IESG Approval certainly _should_ imply that the IESG _understands_ the registration request. - Dissension within the IETF. Like in the case of a WG, the IESG has to evaluate the arguments on their merits; obviously the proposers think that the registration should be allowed, and opposition without a rational basis should no more be allowed to block this registration than it should be allowed to block WG progress. But as the saying goes - this is why you get the big bucks. Did I miss the part where your salary was increased? Among the things to consider here is that the determination must be made in a timely fashion - sometimes there are reasons why
Information on Directorates and Finances
I have put two web pages up at the following URL: http://www.ietf.org/u/chair/ One details the directorates that currently exist in the IETF, with memberships of most of them. The other one is the IETF finances for 2001. The presentation format is subject to modification - if you find things unclear or hard to understand, drop me a line! Harald
Re: Information on Directorates and Finances
Harald, I'd never seen any finances for the ietf, but are these from 2002 or did it just take that long to pull 2001 expenses together? -rick On Mon, 3 Feb 2003, Harald Tveit Alvestrand wrote: I have put two web pages up at the following URL: http://www.ietf.org/u/chair/ One details the directorates that currently exist in the IETF, with memberships of most of them. The other one is the IETF finances for 2001. The presentation format is subject to modification - if you find things unclear or hard to understand, drop me a line! Harald
sole-sourceing IANA function to ICANN for next 3 years
FYI -rick -- Forwarded message -- Date: Mon, 3 Feb 2003 14:15:30 -0500 Subject: FW: US Grants ICANN Extension of Global Domain Powers US Grants ICANN Extension of Global Domain Powers By Kevin Murphy ICANN, which manages policy aspects of the internet's domain name system, is to be granted a three-year extension of its powers to manage the world's country-code domain names, ComputerWire has learned. The US Department of Commerce last week quietly published a document detailing its decision to sole-source the contract for the so-called IANA function to ICANN, as opposed to opening the contract for competitive bidding. ICANN and a spokesperson for the DoC's National Telecommunications and Information Administration both confirmed the extension, although ICANN general counsel Louis Touton added that no contract has yet been signed. IANA is responsible for maintaining the definitive list of which organizations, individuals, and domain servers are associated with approximately 240 country-code top-level domains (ccTLDs), such as .uk, .us, and .fr. The decision will cause concern to some in the international community, particularly those concerned in the policy aspects of the ccTLD industry. Some ccTLD operators had considered a counter-bid for the IANA contract before its March expiration. A statement buried six clicks into a Federal web site heavily suggests that the ICANN-DoC Memorandum of Understanding (MoU) and the IANA contract are essentially inseparable, and that ICANN is the only party fit to run IANA. The NTIA document said that ICANN, having assumed key resources and associated privatization responsibilities under the MoU is therefore the only responsible entity that can continue to provide seamless performance of the IANA functions. As a further link, the three-year IANA contract will come up for renewal at periods of six months, one year, one year, and six months - paced to coincide exactly with the times the MoU comes up for renewal, Touton and the NTIA said. ICANN's Touton added that the decision was made because of how closely linked the policy-making functions of ICANN are with the policy-implementing functions of IANA, and that it wouldn't make sense for a third party to take over IANA. ICANN has been accused in the past of using the IANA function to further its own ends. One of the Herculean tasks in the MoU requires ICANN to sign stable operating agreements with each of the ccTLD operators, but this has proved difficult. In the majority of the cases when ICANN has signed such an agreement, it has coincided with the re-delegation of a ccTLD to a new operator. The most recent such deal was with the new government of Afghanistan. Last October, a number of ccTLDs, disgruntled with their treatment by ICANN over the four years of its existence, said they would consider mounting a bid to take over the IANA function, being the groups most affected by its decisions. But the current international political climate would have made the US venturing outside its borders for a contractor unlikely. Recent denial-of-service attacks against the DNS root servers has created a mindset among some where the DNS is a US national, rather than international, resource that must be protected against terrorism like any physical target. Lisette Zarnowski Register.com, Inc. Manager, Public Relations/Special Events (212) 798-9165 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://216.21.229.207/images/sig_line.gif http://216.21.229.207/images/sig_txt.gif http://216.21.229.207/images/spacer.gif http://216.21.229.207/images/sig_logo.gif http://216.21.229.207/images/sig_line.gif
Re: Information on Directorates and Finances
--On 3. februar 2003 11:33 -0800 Rick Wesson [EMAIL PROTECTED] wrote: Harald, I'd never seen any finances for the ietf, but are these from 2002 or did it just take that long to pull 2001 expenses together? these are from 2001. It's been on my TODO list to get them on a web page forever, but I didn't get around to it before now. I did a presentation on the same type of numbers in London (for 2000), but only in summary form, and it doesn't seem that I remembered to do one in Yokohama. Now that I've done it once, I think the 2002 figures will be much faster Harald -rick On Mon, 3 Feb 2003, Harald Tveit Alvestrand wrote: I have put two web pages up at the following URL: http://www.ietf.org/u/chair/ One details the directorates that currently exist in the IETF, with memberships of most of them. The other one is the IETF finances for 2001. The presentation format is subject to modification - if you find things unclear or hard to understand, drop me a line! Harald
Re: Information on Directorates and Finances
Well done, Harald! I applaud this move towards 'transparency.' One question. In the sentence on the finance page where you wrote: In the US, this is one way in which hotels recover the cost of meeting rooms; in one recent query, the secretariat got a quote on meeting rooms without food for USD 238.000 (at 50% off list price). At a similar meeting where we got the meeting rooms for free, our food and beverages bill was approximately USD 250.000. I'm a little confused as to whether the decimal has been substituted for a comma or whether it's just in the wrong place or both. --aaron Harald Tveit Alvestrand wrote: I have put two web pages up at the following URL: http://www.ietf.org/u/chair/ One details the directorates that currently exist in the IETF, with memberships of most of them. The other one is the IETF finances for 2001. The presentation format is subject to modification - if you find things unclear or hard to understand, drop me a line! Harald ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: Information on Directorates and Finances
--On 3. februar 2003 21:07 -0800 Aaron Falk [EMAIL PROTECTED] wrote: Well done, Harald! I applaud this move towards 'transparency.' One question. In the sentence on the finance page where you wrote: In the US, this is one way in which hotels recover the cost of meeting rooms; in one recent query, the secretariat got a quote on meeting rooms without food for USD 238.000 (at 50% off list price). At a similar meeting where we got the meeting rooms for free, our food and beverages bill was approximately USD 250.000. I'm a little confused as to whether the decimal has been substituted for a comma or whether it's just in the wrong place or both. It's just my Norwegian decimals both numbers are in the ballpark of a quarter million dollars. (Norwegian, and many European languages, use comma to separate units and fractions, and the dot to separate thousands. Sometimes quite confusing) Harald
Fwd: Public Review Issues update
The following has been received from the Unicode Consortium. Comments either to Unicode Consortium according to specified instructions, or to myself as liason from IETF to Unicode Consortium. Regards, Patrik Liason from IETF to Unicode Consortium Begin forwarded message: From: Rick McGowan [EMAIL PROTECTED] Date: tis feb 4, 2003 02:15:32 Europe/Stockholm To: [EMAIL PROTECTED] Subject: Public Review Issues update Please note that the Issues for Public Review have been updated with a new review item regarding tailoring of normalization. Please see issue number 7 on this page: http://www.unicode.org/review/ Instructions for discussion and submision of formal comments are provided on that page. The closing date for review comments is February 28, 2003 (2003-02-28). Also, the review period for issues 1, 4, 5, and 6 is quickly approaching, and these items are expected to be discussed at the next UTC meeting March 4-7 2003. Regards, Rick McGowan Unicode, Inc.
