Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
Dave, Thanks for your clarification, now I understand this has converged to a more contract language issue. At this stage, I may not be able to help on the detail languages since I guess the hoster or IAOC already have been deeply involved in it. Anyhow, I apprecaite that you make everybody more clear on it, thanks. Lastly, I think that everybody have to self-censor about what he does. Thanks for the discussion -Hui 2009/10/2 Dave CROCKER d...@dcrocker.net: Hui, Hui Deng wrote: 1) I personally have attended several standardization meetings such as 3GPP and 3GPP2 in China, Many of us have attended meetings in China and we have found them productive and enjoyable. However all of those other groups conduct their business in a way that is significantly different from the unruly style of the IETF. 3) IETF is doing technical stuff, I don't see why we need to be involved in political stuff. This has been explained repeatedly. First, there is legitimate technical work in the IETF that touches topics which are explicitly prohibited by the contract language. Second, the style of IETF discussions often includes individual comments which are likely to violate the contract. This unruly speech is a consequence of a core principle in the open style of IETF work. 4) China is one of the major member of United Nations, anyhow, come here and see Hui, this really has little to do with China. Rather, the problem is with contract language that I believe we would never accept for any other venue. The only reason we have a debate about this because we are so /eager/ to have an IETF meeting in China! Some folk say that we should ignore the language in the draft contract, because it will not be enforced, except under extreme circumstances. First, it is never appropriate for people signing a contract to assume that it won't be enforced, especially when they cannot really know the exact conditions that will cause it to be enforced. (The term fiduciary responsibility covers this.) Second, these assurances are coming from people who cannot speak for the hotel or the government. Hence, they are merely guessing. Let's be specific: Should the contents of the Group's activities, visual or audio presentations at the conference,or printed materials used at the conference (which are within the control of the Client) contain Note how extensive this is. We are required to control material and speech by everyone, yet the IETF has never really controlled the material or speech of /anyone/. any defamation against the Government of the People's Republic Defamation is really a rather vague word, especially among most of us do not know how it is actually used in China. (Let's be fair. I suspect most of us do not know how it is used as a legal term in the US, or any other country...) So we need to be afraid of violating this, without really knowing what is permitted and what is prohibited. of China, or show any disrespect to the Chinese culture, or Disrespect is an even more vague term and it is coupled with culture which could mean anything having to do with the country's government, history or population, and could even cover reference to Chinese people anywhere in the world. Worse, comments made in the IETF are often disrespectful. We wish they weren't, but again, this is a consequence of how the IETF conducts its business. So the IETF really is being required to make guarantees that change its basic style of operation. violates any laws of the People's Republic of China or feature Language that says that we won't violate the host country's laws is, of course, not necessary -- the laws are the laws and anyone violating them has a problem, no matter whether it is referenced in the contract -- but it probably doesn't hurt to include it. Or rather, the only reason to include it is to set the stage for the financial consequences, specified later... any topics regarding human rights or religion without prior approval from the Government of the People's Republic of China, As has been noted by several folks, the IETF does work that necessarily requires discussing topics that are relevant to human rights. And again, we also have the problem of trying to restrict spontaneous comments that might violate these conditions; yet we have never done that. the Hotel reserves the right to terminate the event on the spot and/or ask the person(s) who initiates or participates in any or all of the above action to leave the hotel premises immediately. This gives the Hotel complete freedom to shut the meeting down according to its own interpretation of conditions that are extremely vague. That's not a reasonable contract condition for us to agree to. (Here's where fiduciary responsibility becomes the real focus, when making an agreement.) The Client will support and assist the Hotel with the necessary
Re: [sasl] Last Call: draft-ietf-sasl-scram
On 9/23/09, Nicolas Williams nicolas.willi...@sun.com wrote: On Wed, Sep 23, 2009 at 07:54:56PM +0200, Simon Josefsson wrote: I have noticed an additional problem related to additional data in SCRAM. RFC 4422 section 5 item 2b says: b) An indication of whether the server is expected to provide additional data when indicating a successful outcome. If so, if the server sends the additional data as a challenge, the specification MUST indicate that the response to this challenge is an empty response. As far as I can tell, SCRAM does not specify that the response to a server-final sent as a challenge MUST be an empty client response. This violates the requirements in RFC 4422 for new mechanisms. I'm not sure that not saying this violates RFC4422: one could argue that this is implied, and it'd be better RFC4422 had been written in such a way that we needn't repeat this over and over in all mechanism specifications. As a co-editor of RFC 4422 this is exactly what I would argue for. But I don't mind new text to cover this. C: Request authentication exchange S: Empty Challenge C: SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: SCRAM server-final C: Empty Response S: Outcome of authentication exchange (Four round-trips, ouch!) Blame SASL, or, rather, SASL application protocols for two of those :) And, of course, you're missing the mechanism negotiation round-trip before that: C: List server SASL mechanisms request S: Server SASL mechanism list response I believe section 5 needs to be rewritten to take all these variants into account. Right now the wordings all assume the last situation. OLD: First, the client sends the client-first-message containing: NEW: If the application protocol does not support optional initial responses, the client will request authentication and the first server challenge MUST be empty. The first non-empty client response is the client-first-message containing: [...] I don't think this is necessary. Agreed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
From: Hui Deng denghu...@gmail.com Lastly, I think that everybody have to self-censor about what he does. It's not clear that (self-)censorship is going to be the worst problem from an IETF in the PRC. One of the things I would be most concerned about is the PRC government using this meeting for propoganda purposes (either internal, or external), as happened with the Olympics. Yes, we are very small fry indeed compared to the IOC, but I'm not interested in lending the IETF's good name to any government. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 addresses eaten by... what? (was: IPv6 standard)
The use of market mechanisms to allocate radio spectrum is now pretty much the norm around the world. The only countries that might object to such mechanisms on ideological grounds are either powerless to object (Cuba, North Korea) or considerably more concerned about ensuring access to IP addresses. (China). Even if there was an intention to resist transfer, it would be impossible to police and would be grossly counterproductive as it would encourage parties to hoard IPv4 addresses 'just in case' they needed them. The real question is pricing. I am pretty sure that the demand for static, non-NATed IPv4 addresses is way less than the supply, so the price should not be prohibitive. The problem is that in the US and many other parts of the world, broadband access is a monopoly or duopoly. so in order for the 5% of Comcast customers who really need a static IP address to ensue that they get one at a fair cost, their only effective recourse at present is to use their regulatory influence to force Comcast to provide non-NAT IPv4 service. Thus exacerbating the supply shortfall. What ISPs should be doing to protect their interests is to require that their access point provider (cable modem/ DSL modem) produce a box that can provide seamless protocol conversion, allowing a native IPv4 service, dual stack IPv4/IPv6 service and IPv6 plus NATed IPv4 to be switched seamlessly. That way they can reduce the demand for IPv4 addresses such that the demand for IPv4 addresses does not exceed supply. If for whatever reason, this is the case and IPv4 addresses are selling for a premium, they can then switch over some number of their customers to IPv6 plus NAT service and sell the addresses on the open market. My guess is that the limiting price for an IPv4 address in this scenario is the cost of a customer service call. Say $10 per address. So imagine that IPv4 addresses hit $10 on the spot market (yes there will be one) and MegaISP has 1 million subscribers, 50% of which have compatible modems (or modems that can be flash upgraded) and that 90% of their customers will be happy with an IPv6+NAT address. MegaISP starts by switching the 500,000 customers it can switch to NATted service. 50,000 customers complain and insist on IPv4 service, thats a customer support call each at $10, so $500,000 Then there is the cost of the NAT boxes to support the customers who are switched - say $1 million So the costs are $1.5 million and at the end they sell off 450,000 IPv4 for $10 each a total of $4.5Million, leaving $3 million in profit and 450,000 saved IPv4 addresses. On Tue, Sep 29, 2009 at 4:19 AM, Shane Kerr sh...@isc.org wrote: Tony, [top-posting since that's what you did] AIUI, the intention is not for the RIRs to be controlling the market, but rather to provide the same value they do now: a location where I can see who is responsible for a given address. I think the RIRs all have a transfer policy now. So when a prefix is sold, what amounts to a transfer of deed needs to happen, the same as if you buy or otherwise acquire land. This is not control of IP sales any more than the local town deed registry controls the real estate market. -- Shane On Mon, 2009-09-28 at 10:13 -0700, Tony Hain wrote: Look at http://www.nro.net/ for the current process. Look at http://www.ebay.com/ for the process once the IANA RIR pools are allocated. There are misguided fantasy discussions about controlling the market in the RIR context, but given that their charters explicitly say that they make no statement about the utility or routing of any allocation, they have absolutely no leverage on whatever transactions a market might produce. Look to the CIDR deployment filtering wars to see that the business side of each ISP will beat down the technical side every time, so expect that the routing system will routinely carry /28-29 IPv4 prefixes in a few years. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weiler-rsync-uri (The rsync URI Scheme) to Informational RFC
I think the point is that the IESG should probably refer the doc to the uri-review team to look for any red flags. Mistakes in URI specs are common (speaking has one that has made some). The editors asked the uri-review list for feedback in July of this year, as required by RFC 4395. -- Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
--On Friday, October 02, 2009 11:55 -0400 Noel Chiappa j...@mercury.lcs.mit.edu wrote: It's not clear that (self-)censorship is going to be the worst problem from an IETF in the PRC. One of the things I would be most concerned about is the PRC government using this meeting for propoganda purposes (either internal, or external), as happened with the Olympics. Yes, we are very small fry indeed compared to the IOC, but I'm not interested in lending the IETF's good name to any government. Noel, any time we meet somewhere that considers us important enough to have a government official, even a local vice-mayor, show up (with press) and deliver a welcoming greeting, we are lending the IETF's... name to [a] government. My recollection is that we've had that happen a lot, and happened in places that certainly drew no particular comments (other than about a few politicians being long-winded) before or after the fact. I think there are some issues with meeting in Beijing, but support for any government isn't one of them. In the interest of clarity, I think there are going to be _some_ issues almost anywhere, e.g., we have met several times in Minneapolis, and had very successful meetings, at times of year when the host and hotel were unwilling to arrange balmy weather. For example, I'm much more worried about the possibility of a few key IETF participants being guilty of the crime of traveling while ill and exhausted, arriving with a fever, and being quarantined and kept out of the meeting for a few days than I am about the meeting being disrupted by the provisions of that contract. And, again, that situation could, in principle, arise in most of the countries of the world that follow WHO recommendations. However, like Dave, I'm hung up on the contractual language, not because I expect behavior that the IETF (or even the Chinese government) would consider bad enough to justify actually canceling a meeting (I believe that the odds of someone being offensive enough to be asked to leave the country are higher, but also much less problematic to the IETF... and not unique to China either). However, I'm concerned that, contractually and regardless of how I assess the odds, a hotel employee could, at his or her own discretion and based on his or her own sensitivities or other concerns, make a decision that would have far-reaching effects. Even then, I'd have little problem if the proposed agreement were entirely between the host and the hotel, with no risks to the IETF other than cancellation of a meeting after it had started -- i.e., that claims by the hotel for consequential financial damages or relief were between the hotel and the host and did not involve the IETF. The host presumably can appraise the risks themselves, possibly obtain insurance if they thought it was necessary, and make whatever decisions that thought appropriate. I'd be even more comfortable with it if the hotel that has all of this power could be sued in a non-Chinese jurisdiction for the costs that individuals or their companies would incur from early departure costs, lost work, etc. Perhaps the latter suggests a way for the IAOC to think about this. Assume that, however unlikely it is, the meeting were called off mid-way and that every IETF participant who attended sued the IASA to recover the costs of leaving China earlier than expected, the prorata costs of unexpectedly attending only part of a meeting, and possibly the value of lost time. Suppose the hotel also tried to recover lost revenue and lost reputation costs as some have suggested in this discussion might be possible. Now consider going out and buying insurance against those risks. There are insurance companies who are happy to do that sort of risk assessment and quote prices (and do it professionally, as if their bottom line depends on it, which it does) and with great skill. If the cost of such insurance is a reasonable add-on to the other costs of holding a meeting in Beijing (or can be passed on to the host), then we go ahead with the meeting. If not, we make another plan. I do not consider Beijing unique in that regard: I'd favor obtaining insurance against premature meeting cancellation for a meeting anywhere in the world, if only to get the professional risk assessment that comes with it. From that perspective, the only thing that is special about this proposed meeting is the unusual contractual language; let an insurance company figure out whether it is important enough to worry about. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Results of Venue Contract Survey
On 18 September 2009 the IAOC requested input via the IETF list and a survey regarding a venue contract provision concerning the hotel's right to terminate the IETF meeting under certain conditions. We sought to determine the impact of this provision on the meeting and the potential financial responsibilities if the meeting were cancelled. The survey closed on 1 October at 0900 EDT. This email is a report on the results of the survey. Note: the verbatim comments made on the survey are not being disclosed as they could identify the respondents, and the survey was intended to be anonymous. Survey Results: 366 took the survey 1. Where are you from? 53% were from North America 25% from Europe 19% from Asia 3% Other 2. How many of the last 6 meetings did you attend? 41% - 6 12% - 5 11% - 4 11% - 3 11% - 2 10% - 1 7% - 0 3. Please check all that apply 96% - ID or RFC Author 32% - Working Group Chair 3% - Area Director 3% - Member of the IAB 2% - Member of the IRSG 4. Have you ever attended a meeting in China? 45% - Yes 55% - No 5. You may have other reasons for not attending, but would this contract provision by itself prevent you from attending? 29% - Yes 58% - No 13% - Don't Know 6. Respondent Status Results Author of ID or RFC: 287 58% would not prevent from attending 29% feel it would prevent them from attending 13% don't know WG Chair: 97 58% would not prevent from attending 27% feel it would prevent them from attending 14% don't know Area Director: 10 80% would not prevent from attending 10% feel it would prevent them from attending 10% don't know IAB Member: 8 63% would not prevent from attending 13% feel it would prevent them from attending 25% don't know IRSG Member: 7 57% would not prevent from attending 14% feel it would prevent them from attending 29% don't know The IAOC has not made a decision as to the venue because negotiations are still underway. However, the IAOC expects to make a decision before IETF 76. The results of the survey and input from the list are being taken into account in the negotiations. The IAOC would like to thank all who have participated on the list and in the survey. Bob Hinden IAOC Chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC' to Proposed Standard
The IESG has approved the following document: - 'Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC ' draft-ietf-dnsext-dnssec-rsasha256-14.txt as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-14.txt Technical Summary This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). Working Group Summary The DNS Extensions Working Group had consensus to publish the document. Document Quality The document received thorough review, and it is expected that vendors supporting DNSSEC will implement SHA-2 once the document is published. During Working Group Last Call, there were objections that an earlier approach, which tied SHA-2 to implementation of NSEC3, would be a barrier for adoption by some vendors, so the specification was changed to avoid the link. Personnel Andrew Sullivan (a...@shinkuro.com) is the Document Shepherd. Ralph Droms (rdr...@cisco.com) is the Responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dhc-vpn-option (Virtual Subnet Selection Options for DHCPv4 and DHCPv6) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Virtual Subnet Selection Options for DHCPv4 and DHCPv6 ' draft-ietf-dhc-vpn-option-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-10-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=7414rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Results of Venue Contract Survey
On 18 September 2009 the IAOC requested input via the IETF list and a survey regarding a venue contract provision concerning the hotel's right to terminate the IETF meeting under certain conditions. We sought to determine the impact of this provision on the meeting and the potential financial responsibilities if the meeting were cancelled. The survey closed on 1 October at 0900 EDT. This email is a report on the results of the survey. Note: the verbatim comments made on the survey are not being disclosed as they could identify the respondents, and the survey was intended to be anonymous. Survey Results: 366 took the survey 1. Where are you from? 53% were from North America 25% from Europe 19% from Asia 3% Other 2. How many of the last 6 meetings did you attend? 41% - 6 12% - 5 11% - 4 11% - 3 11% - 2 10% - 1 7% - 0 3. Please check all that apply 96% - ID or RFC Author 32% - Working Group Chair 3% - Area Director 3% - Member of the IAB 2% - Member of the IRSG 4. Have you ever attended a meeting in China? 45% - Yes 55% - No 5. You may have other reasons for not attending, but would this contract provision by itself prevent you from attending? 29% - Yes 58% - No 13% - Don't Know 6. Respondent Status Results Author of ID or RFC: 287 58% would not prevent from attending 29% feel it would prevent them from attending 13% don't know WG Chair: 97 58% would not prevent from attending 27% feel it would prevent them from attending 14% don't know Area Director: 10 80% would not prevent from attending 10% feel it would prevent them from attending 10% don't know IAB Member: 8 63% would not prevent from attending 13% feel it would prevent them from attending 25% don't know IRSG Member: 7 57% would not prevent from attending 14% feel it would prevent them from attending 29% don't know The IAOC has not made a decision as to the venue because negotiations are still underway. However, the IAOC expects to make a decision before IETF 76. The results of the survey and input from the list are being taken into account in the negotiations. The IAOC would like to thank all who have participated on the list and in the survey. Bob Hinden IAOC Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5648 on Multiple Care-of Addresses Registration
A new Request for Comments is now available in online RFC libraries. RFC 5648 Title: Multiple Care-of Addresses Registration Author: R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami Status: Standards Track Date: October 2009 Mailbox:ryuji.wakik...@gmail.com, vi...@wichorus.com, tsirt...@gmail.com, thierry.er...@inria.fr, nag...@inetcore.com Pages: 36 Characters: 90112 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-monami6-multiplecoa-14.txt URL:http://www.rfc-editor.org/rfc/rfc5648.txt According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS TRACK] This document is a product of the Mobility EXTensions for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
