Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
(moving this back to the IETF list, where the bulk of discussion has been.) Russ Housley wrote: I think everyone agree that the IAB has an oversight role here. Many of the people on this list have already advocated the need for an appeals process to resolve disagreements about the content of notes suggested by the IESG. This is not about the content of the document itself. If it were, then I could understand your concern, but it is only about the content of the note. Russ, While the tenacity that you and the IESG are showing, and the apparent motivation for it, are admirable, the effort seems to be based on some assumptions that should be reconsidered. The first assumption is that there is a real problem to solve here. Given 40 years of RFC publication, without any mandate that the RFC Editor must include a note from the IESG, and without any critical problems resulting, we have yet to see any real case made for changing the current rule, which makes inclusion of an IESG note optional. The second assumption is that an IESG note is sometimes, somehow essential. I believe you will be very hard-pressed to make an empirical case for that assumption, and the problem with trying to make only a logical case is that a competing logical case is always available. In other words, in 40 years of RFCs, the damage that was caused by not having a note added by an authority that is separate from the author, or the damage that was prevented by adding one, is almost certainly absent. That does not make it a bad thing to add notes, but it makes the case for /mandating/ such notes pretty flimsy. The third assumption is that the real locus of control, here, needs to be the IESG. Even though you are now promoting an appeal path, it's a fallback position that derives from the assumption that the IESG should be the ultimate arbiter of all quality assessment, not just for IETF RFCs but for all RFCs. For independent submissions, this distorts the original model, which is that the IESG is merely to be consulted for conflicting efforts, not general-purpose commentary on the efficacy or dangers of an independent document. Really, Russ, it's OK for some things to proceed without having the IESG act as a gatekeeper. The fourth assumption is that an added layer of mechanism, in the form of an appeal path, is worth the cost. An honest consideration of those costs has been absent, yet they are significant. The fifth assumption is the odd view that Jari put forward, namely that creating an appeal path somehow retains the independence of the editor. In other words, impose a mechanism designed to reverse decisions by the editor, but say that the editor retains independence. Confusing, no? The assertion that there is community support for adding this new appeal path is apparently based a non-zero number of supporting posts, rather than on satisfying the rather more stringent requirement to achieve rough consensus support, or anything even close to it. In other words, you got some support, and based on that are claiming that it's the preferred solution. Before adding more management layers, to solve a questionable problem, any claim of community support ought to have stronger evidence than we have so far seen. The IETF has a long history with how to handle calls for change: Has it achieved rough consensus? In the absence of rough consensus the status is supposed to remain quo. The IESG is demanding a change. The IESG has failed to achieve community rough consensus for that change, but the IESG is still claiming a mandate for change. One of the problems with our having rules is that we really are supposed to follow them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
Dave, I'd like to address some of the points you made in your message to Russ re 3932bis: ... The first assumption is that there is a real problem to solve here. Given 40 years of RFC publication, without any mandate that the RFC Editor must include a note from the IESG, and without any critical problems resulting, we have yet to see any real case made for changing the current rule, which makes inclusion of an IESG note optional. As ads for financial products remind us Past performance is not a guarantee of future performance. Since we have been making changes in IETF functions over time, including the RFC Editor function, I don't think it is unreasonable to formalize this aspect of the relationship between the IESG and the RFC Editor, before a problem arises. The second assumption is that an IESG note is sometimes, somehow essential. I believe you will be very hard-pressed to make an empirical case for that assumption, and the problem with trying to make only a logical case is that a competing logical case is always available. In other words, in 40 years of RFCs, the damage that was caused by not having a note added by an authority that is separate from the author, or the damage that was prevented by adding one, is almost certainly absent. That does not make it a bad thing to add notes, but it makes the case for /mandating/ such notes pretty flimsy. I believe that most folks recognize that the public, in general, does not distinguish between RFCs that are the product of IETF WGs, individual submissions, independent submissions, etc. I think the IESG has a legitimate role in ensuring that RFCs that are not the product of WGs are appropriate labelled, and inclusion of an IESG note is a reasonable way to do that. When the RFC series was first established, the need for archival, searchable, open publication of Internet-related documents was a good argument for the autonomy of the RFC Editor function. Moreover, the RFC Editor function pre-dates the existence of the IETF and the IESG, by many years. But, times change. The availability of search engines like Google make it possible for essentially anyone to publish material that is widely accessible, relatively easy to find, and more or less archival. Also, the vast majority of the RFCs published for many years are documents approved by the IESG. Thus it seems reasonable to revisit the degree of autonomy the RFC Editor enjoys relative to the IESG. The current proposal does not change the relationship very much in practice, but I understand that it is an important issue in principle, and the IETF membership has debated it in this context, extensively. The third assumption is that the real locus of control, here, needs to be the IESG. Even though you are now promoting an appeal path, it's a fallback position that derives from the assumption that the IESG should be the ultimate arbiter of all quality assessment, not just for IETF RFCs but for all RFCs. For independent submissions, this distorts the original model, which is that the IESG is merely to be consulted for conflicting efforts, not general-purpose commentary on the efficacy or dangers of an independent document. Really, Russ, it's OK for some things to proceed without having the IESG act as a gatekeeper. My comment above addresses this issue as well. The fourth assumption is that an added layer of mechanism, in the form of an appeal path, is worth the cost. An honest consideration of those costs has been absent, yet they are significant. I think the biggest cost of an appeal mechanism is incurred when appeals arise, although there are costs associated with defining the mechanism. Since you argued above that we ought not expend a lot of effort to deal with problems that have not arisen, maybe we ought not worry about the costs of appeals that have not yet arisen :-). The fifth assumption is the odd view that Jari put forward, namely that creating an appeal path somehow retains the independence of the editor. In other words, impose a mechanism designed to reverse decisions by the editor, but say that the editor retains independence. Confusing, no? I agree that the quote cited above is not a good way to characterize the value of an appeals process. Perhaps a better way to state the value of the appeal process is to say that it provides a way for the Editor to address a situation when it believe that the IESG has insisted on inserting an inappropriate note. I support 3932bis, with the appeal provision. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
2009/10/9 Michael StJohns mstjo...@comcast.net In propaganda, your statement would probably be considered a black and white fallacy. In symbolic logic, it would just be a fallacy. For your statement to be always true, the first clause would have to read Since the IETF ONLY discusses how to make the Internet better and nothing else and it would also have to imply that nothing the the IETF discusses to make the Internet better could be considered as any other class of discussion I never thought it could be understood differently: anything different would be rude for ISOC. So, what you personnalité want is to be sure that whatever off topic you may want to discuss it will be permitted by the local law? This sounds like invading foreign countries and saying, hey! guys, I am the IETF, I am your law now.. In fact you may genuinely think youcann ... But, what surprises me is that you seems to consider that discussing any non defined off topic matter is something the US law and order permit you. You surely pull my leg. Since the IETF discusses how to make the Internet work better, the only reason why IETF members could feel worried is that they would intend to discuss how to build a better working Internet that would be prohibited in China? Either this means considering splitting the Internet from 1/3 of its users. Or that the IETF can develop standards that do not take local users' legitimate and/or legal needs into consideration. Or did I miss something? What about the legality of a similar case in the USA? Patrick Suger ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
At 03:19 09-10-2009, Stephen Kent wrote: As ads for financial products remind us Past performance is not a guarantee of future performance. Since we have been making changes in IETF functions over time, including the RFC Editor function, I don't think it is unreasonable to formalize this aspect of the relationship between the IESG and the RFC Editor, before a problem arises. By over-formalizing the procedures, the IETF will end up with a rigid process. I believe that most folks recognize that the public, in general, does not distinguish between RFCs that are the product of IETF WGs, individual submissions, independent submissions, etc. I think the IESG has a legitimate role in ensuring that RFCs that are not the product of WGs are appropriate labelled, and inclusion of an IESG note is a reasonable way to do that. Section 1.1 of the draft mentions that: The IESG may provide an IESG note to an Independent Submission or IRTF Stream document to explain the specific relationship, if any, to IETF work. That's a may. From what you said, I deduce that you would prefer that line to say: The IESG will provide an IESG note to an Independent Submission ... The reasons for the IESG Note are mentioned in Section 3. None of them are about a label saying that the RFC is not a product of a WG. When the RFC series was first established, the need for archival, searchable, open publication of Internet-related documents was a good argument for the autonomy of the RFC Editor function. Moreover, the RFC Editor function pre-dates the existence of the IETF and the IESG, by many years. But, times change. The availability of search engines like Google make it possible for essentially anyone to publish material that is widely accessible, relatively easy to find, and more or less archival. Also, the vast majority of the RFCs published for many years are documents approved by the IESG. Thus it seems reasonable to revisit the degree of autonomy the RFC Editor enjoys relative to the IESG. The current proposal does not change the relationship very much in practice, but I understand that it is an important issue in principle, and the IETF membership has debated it in this context, extensively. An open source advocate once suggested to me that I could use Geocities to publish material. That site is closing this month. There are differences between publishing something on your web site and publishing a RFC. The latter does not require search engine optimization for wide dissemination. A RFC has intrinsic qualities because of the way it is produced. There are some RFCs with IESG notes, such as RFC 4144, which I read as good advice. The current proposal undermines the independence of the RFC Editor (ISE in practice). It changes the relationship from one where the various parties should work together and come to an agreement to a tussle between the RFC Editor and the IESG. I don't think that an appeal is a good idea. I didn't object to it as the IESG folks may feel better if they had that mechanism. However, I do object to making the outcome mandatory. At 00:18 09-10-2009, Dave CROCKER wrote: The IESG is demanding a change. The IESG has failed to achieve community rough consensus for that change, but the IESG is still claiming a mandate for change. There doesn't seem to be a concern about achieving rough community consensus in this case as the IESG really wants the change. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
Hi David, On Oct 6, 2009, at 3:30 PM, David Morris wrote: To the best of my knowledge, in the countries you mention, there was no contractual risk that normal activities of the IETF would result in arbitrary cancelation of the remainder of the meeting. That is a good point. The particular contractual agreement we are being asked to make in this case is different from other cases, and I do find it problematic. I am especially concerned about the fact that the entire IETF meeting could be cancelled due to the bad contact of one or a few participants. Given the open nature of IETF participation, those IETF participants wouldn't even need to be members of the IETF community. They could just be people who showed up to cause trouble... Margaret ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
Dave: You have the motivations for rfc3932bis completely confused. The IESG is not the source for the proposed changes to RFC 3932. RFC 3932 as it stands works fine for the IESG, and the IESG continues to operate under it. The Independent submission stream and IRTF stream do not like the IESG notes that are mandated by RFC 3932. The approval of draft-iab-streams-headers-boilerplates by the IAB offers an opportunity to revisit this question. So, you seem to be reviewing this discussion with the wrong context. Below, I'll respond to each of you assumptions and assertions I think everyone agree that the IAB has an oversight role here. Many of the people on this list have already advocated the need for an appeals process to resolve disagreements about the content of notes suggested by the IESG. This is not about the content of the document itself. If it were, then I could understand your concern, but it is only about the content of the note. While the tenacity that you and the IESG are showing, and the apparent motivation for it, are admirable, the effort seems to be based on some assumptions that should be reconsidered. The document that was brought to Last Call did not have a section on appeals. It was added because of the Last Call discussion. I find it most interesting that the people voicing the strongest concerns on both sides of the issue are former IESG members. The first assumption is that there is a real problem to solve here. Given 40 years of RFC publication, without any mandate that the RFC Editor must include a note from the IESG, and without any critical problems resulting, we have yet to see any real case made for changing the current rule, which makes inclusion of an IESG note optional. This repeats points that were made in the Last Call discussion. The second assumption is that an IESG note is sometimes, somehow essential. I believe you will be very hard-pressed to make an empirical case for that assumption, and the problem with trying to make only a logical case is that a competing logical case is always available. In other words, in 40 years of RFCs, the damage that was caused by not having a note added by an authority that is separate from the author, or the damage that was prevented by adding one, is almost certainly absent. That does not make it a bad thing to add notes, but it makes the case for /mandating/ such notes pretty flimsy. This repeats points that were made in the Last Call discussion; however, several people wanted to include a path for dispute resolution before it was needed, not in the heat of the dispute. The third assumption is that the real locus of control, here, needs to be the IESG. Even though you are now promoting an appeal path, it's a fallback position that derives from the assumption that the IESG should be the ultimate arbiter of all quality assessment, not just for IETF RFCs but for all RFCs. For independent submissions, this distorts the original model, which is that the IESG is merely to be consulted for conflicting efforts, not general-purpose commentary on the efficacy or dangers of an independent document. Really, Russ, it's OK for some things to proceed without having the IESG act as a gatekeeper. I disagree with this characterization. The IESG is supposed to ensure that the non-IETF streams are not used as an end run around the IETF standards process or the IANA registration process for any IETF-related registries. The whole point of RFC 3932 was to make this situation clear, and define process for it. The IESG is not responsible for the quality of the content for RFCs outside the IETF stream. The appeal path being discussed is about the content of an IESG note, not the content of the RFCs outside the IETF stream. The fourth assumption is that an added layer of mechanism, in the form of an appeal path, is worth the cost. An honest consideration of those costs has been absent, yet they are significant. This point was not in the Last Call discussion. If your earlier assumption is correct, then this appeal path will never be exercised. Others have stated that they expect it will be exercised quite soon. The fifth assumption is the odd view that Jari put forward, namely that creating an appeal path somehow retains the independence of the editor. In other words, impose a mechanism designed to reverse decisions by the editor, but say that the editor retains independence. Confusing, no? How can you call this an assumption? I think Jari was very clear in his note, but I do not see it as an assumption. Again, neither the IAB nor the IESG would be making any decision regarding the content of the published document. The assertion that there is community support for adding this new appeal path is apparently based a non-zero number of supporting posts, rather than on satisfying the rather more stringent requirement to achieve rough consensus
Re: I-D Action:draft-davies-dtnrg-uri-find-00.txt
On Fri, 2009-10-09, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Adding the find Operation to the dtn: URI Scheme Author(s) : E. Davies, A. Doria Filename: draft-davies-dtnrg-uri-find-00.txt Pages : 7 Date: 2009-10-09 This document discusses the addition of a new operation to the proposed dtn: URI (Uniform Resource Identifier) scheme. The new find operation would provide support for DTN anycast services. I find it odd that the acronym URI is explained (IMHO unnecessarily) but dtn is not. Even reading the draft, I could not determine what dtn means. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Support for publication of draft-housley-iesg-3932bis
I have reviewed the latest revisions of the update to rfc 3932 and believe that would be a reasonable way forward. Thanks to the IESG and authors for being responsive to the last call concerns. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
Russ, On 2009-10-10 07:16, Russ Housley wrote: Dave: You have the motivations for rfc3932bis completely confused. The IESG is not the source for the proposed changes to RFC 3932. RFC 3932 as it stands works fine for the IESG, and the IESG continues to operate under it. The Independent submission stream and IRTF stream do not like the IESG notes that are mandated by RFC 3932. Points well taken. I think I'm going to challenge Jari's reading of rough consensus in his message of Sept. 13: http://www.ietf.org/mail-archive/web/ietf/current/msg58391.html I think the discussions around the -09 and -10 drafts have actually shown that there is no consensus to change from the current model, reflected in the -08 draft, where the IESG merely *requests* the editor to include an IESG note, and the IAB is involved only as defined in RFC 4846. Our general practice when there is no consensus to change a rule is not to change it. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
On Fri, Oct 09, 2009 at 07:04:43PM +0200, Patrick Suger wrote: I never thought it could be understood differently: anything different would be rude for ISOC. So, what you personnalité want is to be sure that whatever off topic you may want to discuss it will be permitted by the local law? This sounds like invading foreign countries and saying, hey! guys, I am the IETF, I am your law now.. In fact you may genuinely think youcann ... I don't think anyone is actually saying this. What folks are in fact saying is that out of _respect_ of Chinese local law, which apparently makes illegal many things which normally would be discussed at IETF metings, maybe it wouldn't be a good idea to hold an IETF meeting in China. The counterargument seems to be, naaah, don't worry, even though there is a contract that says these sorts of things aren't allowed, and if they happen a hotel employee can shut down the entire meeting --- they won't be enforced and don't worry your pretty little heads about such things. So if China wants to make various things illegal to discuss, that's fine. We should respect that. It doesn't mean that we should hold an IETF meeting there, though. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
On Fri, 9 Oct 2009, Theodore Tso wrote: I don't think anyone is actually saying this. What folks are in fact saying is that out of _respect_ of Chinese local law, which apparently makes illegal many things which normally would be discussed at IETF metings, maybe it wouldn't be a good idea to hold an IETF meeting in China. I don't think that it is apparent that many things which would normally be discussed at IETF meetings would be illegal to discuss in China, but, yes, that is the core of the argument here. The counterargument seems to be, naaah, don't worry, even though there is a contract that says these sorts of things aren't allowed, and if they happen a hotel employee can shut down the entire meeting --- they won't be enforced and don't worry your pretty little heads about such things. The counterargument is a little more complex than that, but it's fairly obvious that having a hotel employee determine what can and cannot be said is not an acceptable solution, so that's being worked on. So if China wants to make various things illegal to discuss, that's fine. We should respect that. It doesn't mean that we should hold an IETF meeting there, though. Right, but the crucial word in your statement is if and whether various things fall into the category of topics normally discussed at an IETF meeting. Again, this is being worked on. Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
Dave, The first assumption is that there is a real problem to solve here. I think there is a real problem, and that is the need to modernize the headers and boilerplates so that they are more reasonable for each stream. This includes things like getting rid of derogatory IESG notes, which none of us likes. Of course, headers and boilerplates changes need to be accompanied by the corresponding change in 3932. THAT is the reason for the 3932bis draft. The trouble is, of course the final 3932bis needs to take the opinions of the community into account (and be acceptable to the approving bodies). This is why we have discussed all the changes. I do not see a lot of other options than the compromise position if completing 3932bis and the rest of the system of changes is the goal. We can have differing opinions on whether there's an issue with forcing/requesting IESG notes, but it is a fact that there are many people on both sides of this argument. I sincerely hope that we are not going to ignore their opinions and choose either extreme side as the final result. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
From: Michael StJohns mstjo...@comcast.net For the PRC we've been told (in black and white as part of a legal document - not as anecdotal information) that a) certain acts and topics of discussion are forbidden by law or contract ... ... With respect to ... any of our hosts in the past, show me the contract language, laws, or other indication where things normally discussed or designed at an IETF would be considered illegal. Interesting point. I can recall a number of countries with _export_ restrictions on some things, and perhaps one with a _use_ restriction, but I can't think of one where discuss[ion] or design[ing] anything would have been prohibited. Did I too miss one? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Legality of IETF meetings in PRC. Was: Re: Request for communityguidance on issue concerning a future meeting of the IETF
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Noel Chiappa Sent: Friday, October 09, 2009 4:03 PM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: Re: Legality of IETF meetings in PRC. Was: Re: Request for communityguidance on issue concerning a future meeting of the IETF From: Michael StJohns mstjo...@comcast.net For the PRC we've been told (in black and white as part of a legal document - not as anecdotal information) that a) certain acts and topics of discussion are forbidden by law or contract ... ... With respect to ... any of our hosts in the past, show me the contract language, laws, or other indication where things normally discussed or designed at an IETF would be considered illegal. Interesting point. I can recall a number of countries with _export_ restrictions on some things, and perhaps one with a _use_ restriction, but I can't think of one where discuss[ion] or design[ing] anything would have been prohibited. Did I too miss one? Noel Since people mostly use crypto technology as a straw-man for something they think it is illegal to discuss in China, I googled Cryptography Conference China which yields at least the following: http://books.google.com/books?id=2IrIh6sYl8cCdq=cryptography+conference +chinaprintsec=frontcoversource=blots=-FSbcy9jzfsig=PycGmAPHcpqrTzDL 79R1pERBFmMhl=enei=PKfPSo72HZOoNv3YhfEEsa=Xoi=book_resultct=result resnum=4ved=0CBIQ6AEwAw#v=onepageq=f=false, proceedings of the 5th International Conference, Applied Cryptography and Network Security (2007) http://books.google.com/books?id=k9g8nEfe7fcCdq=cryptography+conference +chinaprintsec=frontcoversource=blots=RyB0ytWPposig=JBHhOhIkMRgkRsN5 P2IjFK_n88Ihl=enei=PKfPSo72HZOoNv3YhfEEsa=Xoi=book_resultct=result resnum=7ved=0CBkQ6AEwBg#v=onepageq=f=false, proceedings of the 10th International Conference on Practice and Theory in Public Key Cryptography, Beijing, China, April 2007 It is probably safe to say that it is not illegal to discuss cryptography in China. Googling firewall security conference china yields at least the following: http://sites.google.com/site/asergrp/projects/policy which contains further a list of publications and conferences held in China (Shanghai and Beijing), some IEEE/IFIP, for example, 1st IEEE international workshop on security in software engineering held in Beijing in 2007. It is probably also safe to say that it is not illegal to discuss firewall, software security in China. Thanks, Jerry -- Jerry Huang, ATT Labs, +1 630 810 7679 (+1 630 719 4389, soon) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
Theodore, you will excuse me. I am afraid this discussion is not real. I am only interested in the Internet working better, all over the place, including in China and in the USA. 1) this lasting debate decreases the credibility of the IETF to be able to build such a network, at least in its Chinese part. This is worrying duing the IDNABIS last call, no one seems to care about.No more than the IETF seems to care about a proper support of the orthotypography of many languages. 2) it also shows the lack of international experience of IETF. This is embarassing since it is supposed to keep developping the international network. It also seems that there is a particular lack of coordination with its sponsors. What is worrying since the IETF must keep being funded. Look, a few basic questions need to be raised: (a) IETF is an affiliate of ISOC (b) ISOC has an affiliate in China (c) if IETF may discuss off topic issues anywhere in the world that conflict with the Chinese law, this embarasses ISOC China the same as if was discuss in Beijing. (d) what is the position of the ISOC China Chair? What is the list of IETF topics he thinks in violation with the Chinese rules (for example the WhoIs related issues are in violation of most of the privacy laws in the world. (e) upon ISOC China's position, what is the position of the ISOC BoD? (f) has the ISOC Chair and the IETF Chair considered inviting the Chinese Minister of Datacommunications? (g) many hurt Chinese engineers participate to the IETF and very politely do not react: have them been invited to comment? (h) has a Chinese Embassy been called upon and asked what IETF topics might be conflicting? etc. etc. Sorry for being so basic. But I am very embarassed for the stability of the network if such questions are so much discussed. Best Patrick Suger 2009/10/9 Theodore Tso ty...@mit.edu On Fri, Oct 09, 2009 at 07:04:43PM +0200, Patrick Suger wrote: I never thought it could be understood differently: anything different would be rude for ISOC. So, what you personnalité want is to be sure that whatever off topic you may want to discuss it will be permitted by the local law? This sounds like invading foreign countries and saying, hey! guys, I am the IETF, I am your law now.. In fact you may genuinely think youcann ... I don't think anyone is actually saying this. What folks are in fact saying is that out of _respect_ of Chinese local law, which apparently makes illegal many things which normally would be discussed at IETF metings, maybe it wouldn't be a good idea to hold an IETF meeting in China. The counterargument seems to be, naaah, don't worry, even though there is a contract that says these sorts of things aren't allowed, and if they happen a hotel employee can shut down the entire meeting --- they won't be enforced and don't worry your pretty little heads about such things. So if China wants to make various things illegal to discuss, that's fine. We should respect that. It doesn't mean that we should hold an IETF meeting there, though. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
On Fri, 9 Oct 2009, Patrick Suger wrote: 2) it also shows the lack of international experience of IETF. This is embarassing since it is supposed to keep developping the international network. It also seems that there is a particular lack of coordination with its sponsors. What is worrying since the IETF must keep being funded. Look, a few basic questions need to be raised: (a) IETF is an affiliate of ISOC True, ISOC is the umbrella organization for the IETF proving legal incorporation and financial support. (b) ISOC has an affiliate in China Not true. The Internet Society of China is not affiliated with ISOC. Unless you mean a certain chapter on a certain island, but let's not have that debate here, OK? (c) if IETF may discuss off topic issues anywhere in the world that conflict with the Chinese law, this embarasses ISOC China the same as if was discuss in Beijing. (d) what is the position of the ISOC China Chair? What is the list of IETF topics he thinks in violation with the Chinese rules (for example the WhoIs related issues are in violation of most of the privacy laws in the world. The Internet Society of China is not the host for the proposed meeting and their position on what might or might not violate Chinese rules is not any more or less relevant than any other expert opinion. (e) upon ISOC China's position, what is the position of the ISOC BoD? (f) has the ISOC Chair and the IETF Chair considered inviting the Chinese Minister of Datacommunications? It would be up to the HOST to invite high-ranking officials to the meeting, this isn't really something the IETF Chair or the ISOC BoT gets involved in typically. We don't really (with a few minor exceptions) organize conferences and invite speakers. (g) many hurt Chinese engineers participate to the IETF and very politely do not react: have them been invited to comment? Everyone on the IETF mailing list has been invited to comment and that certainly includes Chinese engineers. (h) has a Chinese Embassy been called upon and asked what IETF topics might be conflicting? etc. etc. As has been pointed out by others, you cannot typically ask a government offical or a department for a list of legal topics. This isn't likely going to get us anywhere useful, ignoring the type of delays one can typically expect if such a question is even acknowledged or answered. Sorry for being so basic. But I am very embarassed for the stability of the network if such questions are so much discussed. Best Patrick Suger Don't be embarrassed! IETF participants are proud of the fact that we get to debate any topic for any amount of time without restrictions, moderation, courtesy, and so on. It's not always the most tidy debate to watch, but it is very much part of our culture. Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
--On Friday, October 09, 2009 17:03 -0400 Noel Chiappa j...@mercury.lcs.mit.edu wrote: Interesting point. I can recall a number of countries with _export_ restrictions on some things, and perhaps one with a _use_ restriction, but I can't think of one where discuss[ion] or design[ing] anything would have been prohibited. Did I too miss one? Noel, I don't think it moves the discussion forward one way or the other, but I can certainly remember times in the US in which discussions of certain types of cryptographic topics with foreign nationals present was treated as export of cryptographic technology and subject to all sorts of restrictions as a result. It may have been an export restriction rather than a discussion restriction, but the practical difference was zero. You could quite properly and correctly respond that there was a lot of resistance from the relevant communities and that the period of prior restraint on papers to be presented at such meetings didn't last very long, but it did occur. Similarly, if one assumed that I had learned enough as an undergraduate and from the public literature (i.e., without depending on any security clearances or other special access) to have a fairly good idea how to build a nuclear weapon and what the key parameters are, I think I would still be violating US law to stand up in a public meeting and describe how to do it. Certainly that would have been the case some years ago; I haven't spent a lot of time (or any time at all) tracking the evolution of law and regulations in that area. I think the Chinese situation is different, largely because of the meeting cancellation and hotel discretionary provisions (and, since Ole and others have told us several times that the IAOC is working on a different plan in those areas, I'm trying to sit quietly until I see what that process comes up with). Certainly different governments are going to be sensitive about different things (and fewer or more of them). But I don't think it helps to exaggerate the differences by suggesting that there are no restrictions on discussion of sensitive topics anywhere else in the world. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
On Fri, Oct 09, 2009 at 01:44:17PM -0700, Ole Jacobsen wrote: On Fri, 9 Oct 2009, Theodore Tso wrote: I don't think anyone is actually saying this. What folks are in fact saying is that out of _respect_ of Chinese local law, which apparently makes illegal many things which normally would be discussed at IETF metings, maybe it wouldn't be a good idea to hold an IETF meeting in China. I don't think that it is apparent that many things which would normally be discussed at IETF meetings would be illegal to discuss in China, but, yes, that is the core of the argument here. Well, one of the big problems with China is that given that exactly how its local laws will be applied isn't crisply defined, and a huge amount of discretion can be applied by a mandarins (bureaucrats) or in the case of the contract, by a hotel employee. Worse yet, its laws are very vague (where insulting Chinese culture can be enough to get a blog to get haromonized or censored) --- and by the wording of the hotel contract, enough to get us thrown out on our ear. And given that human rights is a very expansive term, and that privacy, such sa what might be described by the Geopriv wg could very will infringe on the verboten human rights restriction, it's very hard for *anyone* to give any guarantees. Which is why I used the word apparently --- not in the sense of something being apparent, but in the sense of maybe, we're not sure, and by keeping things vague the Chinese government is probably hoping that people will self-censor themselves because of the inherent vagueness of words such as 'show any disrespect or defamation against the Government of the People's Republic of China'. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
(g) many hurt Chinese engineers participate to the IETF and very politely do not react: have them been invited to comment? Everyone on the IETF mailing list has been invited to comment and that certainly includes Chinese engineers. Indeed, I wonder if there is something to be learned from the conspicuous absence of comment by all but a very few Chinese participants. --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
Date:Fri, 09 Oct 2009 14:16:37 -0400 From:Russ Housley hous...@vigilsec.com Message-ID: 20091009181642.626a8f24...@odin.smetech.net | You have the motivations for rfc3932bis completely confused. The | IESG is not the source for the proposed changes to RFC 3932. RFC | 3932 as it stands works fine for the IESG, and the IESG continues to | operate under it. The Independent submission stream and IRTF stream | do not like the IESG notes that are mandated by RFC 3932. I suspect that you, the IESG, and perhaps some others (perhaps even the RFC editor) are confused as to the import of that RFC, or any RFC, in this area. The IESG, and the IETF, simply do not have the power to tell the RFC editor what to do, it isn't in the IETF's job description to do that. Whatever the IESG says, whatever RFC3932 says, and whatever the result of this current waste of everyone's time is, the RFC editor is completely entitled (if he/she/it feels the need in a particular circumstance) to simply ignore the IETF, the IESG, and anyone else not specifically having some oversight capacity over the RFC editor (which does not include the IETF). The RFC editor has agreed to send independent submissions to the IESG for review, and that's fine, as it is for the RFC editor to accept advice from the IESG (or anyone else the RFC editor decides to consult), or to reject that advice if the editor believes that it doesn't advance the overall purposes of the RFC series. Nothing the IETF can do can change that, why is everyone wasting time on this? kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-l3vpn-ospfv3-pece (OSPFv3 as a PE-CE routing protocol) to Proposed Standard
The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'OSPFv3 as a PE-CE routing protocol ' draft-ietf-l3vpn-ospfv3-pece-03.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-23. 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. Please note that draft-ietf-l3vpn-ospfv3-pece-03.txt contains a normative reference to RFC2547, which is an informational RFC and is therefore currently a downref. This reference will be moved to be an informative reference prior to publication as an RFC. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ospfv3-pece-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17761rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-hammer-oauth (The OAuth Core 1.0 Protocol) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'The OAuth Core 1.0 Protocol ' draft-hammer-oauth-03.txt as an Informational RFC 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-11-06. 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-hammer-oauth-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17736rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Defining Well-Known URIs ' draft-nottingham-site-meta-03.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-11-06. 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-nottingham-site-meta-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17778rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
