RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard
Rui, While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP, and quite understanding the reasoning behind reusing existing formats, I am puzzled by two of your statements. First, that Y.1731 CCMs would ease more vendor's implementations to converge to the 50ms protection timescale. One of the major problems with Y.1731 is the lack of a 100 packet per second rate, forcing the use of 300 packets per second at high resource cost. I feel that 50 ms protection requirements are the best reason NOT to use Y.1731. Second, that the mechanisms in Y.1731 are sufficiently simple to allow some hardwarization. The other main fault with Y.1731 is its fracturing of the capabilities among so many different OAM message types, rather than realizing that there are really only two OAM types (one way and reflecting), with options for various monitoring or measurement functions. If you only need CCMs, yes Y.1731 is easy (but so is any other heartbeat format). Once you want to do CCs, CCs for protection (G.8031/G.8032 require their own), packet loss measurement, and delay measurement, it becomes a nightmare. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rui Costa Sent: Monday, October 05, 2009 11:27 To: ietf@ietf.org Cc: Adrian Farrel Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard SDH and EoSDH networks are widely used by Portugal Telecom Comunicacoes (PTC) and TMN (respectively the incumbent operator in Portugal and PT group's mobile operator), as well as foreign PT's clients (Brazilian Vivo, for instance). These operators are used to both SDH and Ethernet's OAM paradigm. We ask you therefore to consider that MPLS-TP OAM protocols MUST allow equivalent OAM mechanisms. Being more precise, we would like to use the same protocol messages, to give/have the same touchfeel we had in SDH and for less time in ETH. In SDH... -it allows you at each end to check you have signal reception and notify the other end when you don't (RDI) -it does so at different levels (in SDH you can have it both for each VC and for the STM) -it has a means by which to exchange an APS protocol In ETH... -we've been using Y.1731 in EoSDH systems; it was the ITU standard developed for this purpose and was thought in the same principles stated for SDH; the most logical evolution would hence be to use the same PDUs and mechanisms as faithfully as possible with an adequate MPLS-TP encapsulation -MEF defined performance monitoring functions for frame loss measurement [FL], delay measurement, delay variation measurement, which are also addressed in Y.1731 The main reason to use the same PDUs as in Y.1731 is probably the same i guess and respect in RFC5654 2nd general requirements: economy. We can't though forget this requirement list will have impact on ITU standards and that, although much of the work in MPLS-TP is IETF's merit and sweat, probably no one would need it if ITU didn't start T-MPLS (whose interoperability problems with MPLS/IP were afterwards pointed out by IETF and originated all the work we can see now). I would also like to point out that the mechanisms in Y.1731 are sufficiently simple to allow some hardwarization, which would ease more vendor's implementations to converge to the 50ms protection timescale, allowing a way to do this in a cheaper, more scalable and miniaturized way. Thank You for your time. Best Regards, Rui Costa ___ 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: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard
On Thu, Oct 8, 2009 at 8:43 AM, Yaakov Stein yaako...@rad.com wrote: Rui, Hi all, While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP, and quite understanding the reasoning behind reusing existing formats, I am puzzled by two of your statements. First, that Y.1731 CCMs would ease more vendor's implementations to converge to the 50ms protection timescale. One of the major problems with Y.1731 is the lack of a 100 packet per second rate, forcing the use of 300 packets per second at high resource cost. hemm --- T-REC-Y.1731-200802 --- 7.1.1 CCM (with ETH-CC information) Transmission When ETH-CC is enabled, a MEP periodically transmits CCM frames as often as the configured transmission period. Transmission period can be one of the following seven values: - 3.33ms: default transmission period for protection switching application (transmission rate of 300 frames/second) - 10ms: (transmission rate is 100 frames/second) ^^ --- Even if I'm not a big fan of it I have to say that 100 pps is foressen by Y.1731 (and even by your ID, http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-03, Section 4.1.1) [cut] Y(J)S Ciao FF ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAMin MPLS Transport Networks) to Proposed Standard
All, comments as the document shepherd. We have comments on the draft-ietf-mpls-tp-oam-framework in IETF last call from Yoshinori Koike, Jonathan Sadler and Ruiquan Jing. All are subscribed to IETF lists that were included in the working group last calls. 1. There are comments for the same the look and feel for operations across different networks based on different technologies, on OAM interoperability between different technologies. 2. There are comments on interworking/ineroperability/translation between networks based on different technologies. 3. There is a comment that the involvement (awarness) of the MPLS-TP work is not good enough on the ITU-T side. 4. There is a requirement to change the MEP/MIP architecture. 5. There is a comment that wants to add new information that is not technical in it character to the document. For comments on (1), this is a bit unclear, I assume that we are not talking about look and feel of bits on the wire but look and feel for the operational interfaces and procedures. This is captured in the overall MPLS-TP requirements: To realize these goals, it is essential that packet-transport technology be available that can support the same high benchmarks for reliability and operational simplicity set by SDH/SONET and OTN technologies. and Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management. So this is taken care of. For comments on (2). This was discussed during working group last call and prior, and it was discussed on the ITU-T ad hoc team list during the period when a response was written in response to the MPLS WG last call. The IESG position is that interworking different technologies is out of scope for the MPLS-TP project. The ITU-T did not make a request to include this requirement within MPLS-TP. In liaison https://datatracker.ietf.org/documents/LIAISON/file706.pdf from the ITU-T it was agreed that if and when ITU-T converges on such requirements they will be taken to the IETF through the MPLS change process (RFC4929). This comment should also be resolved. Comment 3, on ITU-T participation in the MPLS-TP project and in the review of the MPLS-TP documents I strongly object to to this comment, the entire project has been set up to guarantee that we have a good flow of information between the two organizations. Tthere are plenty of opportunities for the ITU-T to provide input both through their own procedures and through normal IETF procedures. Comments 4. The maintenance architecture as it is defined operates with functional groups that could be attached to e.g. an LSP at different points. MEPs are Maintenance End Points and can actively generate e.g. OAM flows and traffic to localize failures. MIPs are Maintenance Intermediate Points, which are passive and can only respond if a request are sent to them. The requirements involves a total re-wrap of the Maintenance architecture, it was discussed in Q10/15 and turned down as not aligned with the rest of the requirements we received form other operators. The MPLS-TP maintenace architecture is further explained and expanded upon in draft-ietf-mpls-tp-oam-framework. Further discussion on the maintenance architecture should take place in the context of that document, rather han in the context of the requirements document that should focus on functional requirements. Comment 5. This is a bit trickier since it asks for substantial additions, that is not requirements but descriptive text and tables. Given the nature of the information I'd would like to take it as an input to the MPLS-TP OAM Framework where it would fit nicely. /Loa -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
Nicolas Williams wrote: On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote: On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote: [...] -- 1.2, last bullet: What is the referent for this? Is there perhaps a missing word(s), or maybe this paragraph belongs with the previous bullet? The latter. (This == Hi()) Incidentally, Hi() should be shown as taking the iteration count as an argument. Fixed in my copy. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
Nicolas Williams wrote: On Wed, Sep 23, 2009 at 08:22:25PM -0500, Ben Campbell wrote: -- 2nd paragraph: ...increase the iteration count over time. Can you elaborate on how this helps, and possibly offer guidance on how implementations should use it? Good point. With SCRAM as specified, a server cannot increase the iteration count without somehow getting access to the cleartext password. If the server were to store SaltedPassword _and_ U_iteration_count (from Hi()'s internals), then the server could compute a new SaltedPassword and U_iteration_count with a higher iteration count. However, the server isn't intended to store SaltedPassword, rather, the server stores StoredKey and ServerKey, and there's a reason for this: a server that's never authenticated a given user before cannot impersonate that user, but if the server were to store SaltedPassword, then the server could impersonate the user. Thus, to increase the iteration count over time requires, effectively, changing the user's password. This is probably worth pointing out. I tried to clarify that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard
Hello Yaakov, 1. [YS] One of the major problems with Y.1731 is the lack of a 100 packet per second rate, forcing the use of 300 packets per second [RC] I don't understand your 1st claim. Would you be so kind as to detail it to me a bit? In Y.1731, 7.1.1 CCM (with ETH-CC information) Transmission [...] * 10ms: (transmission rate is 100 frames/second) [...] Table 9-3 - CCM Period Values [...] Might you be referring to G.8031's 11.2.4 Transmission and acceptance of APS? If so, isn't it true that it isn't Y.1731 that creates this but G.8031 or another standard imposing that to G.8031? Besides... Is it really imposing? I think having seen words like desirable or should there... [Thank you, Francesco] 2. [YS] The other main fault with Y.1731 is its fracturing [...] among so many different OAM message types, [...] If you only need CCMs, yes Y.1731 is easy (but so is any other heartbeat format) [...] Once you want to do CCs, CCs for protection (G.8031/G.8032 require their own), packet loss measurement, and delay measurement, it becomes a nightmare. [RC] And isn't CCM simplicity a worthy characteristic... The main characteristic? In SDH, the CPU gets an alarm from HW. If you could have a simple means, easily implemented in HW to give firmware the same interface, then you wouldn't need burdening uPs with extra assembling/disassembling PDUs, right? Or you would, if that was your preferred modus operandi. You could choose. As for your other concerns: in principle, i wouldn't oppose adding Y.1731 PDUs that could integrate several functions, if those were integrated in Y.1731 philosophy and accepted by other ITU members. However, that was proposed recently and is still under discussion, whereas we have to take a decision now. Thank you for your time. Best Regards, Rui -Original Message- From: Francesco Fondelli [mailto:francesco.fonde...@gmail.com] Sent: quinta-feira, 8 de Outubro de 2009 9:33 To: Yaakov Stein Cc: Rui Costa; ietf@ietf.org; Adrian Farrel Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard On Thu, Oct 8, 2009 at 8:43 AM, Yaakov Stein yaako...@rad.com wrote: Rui, Hi all, While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP, and quite understanding the reasoning behind reusing existing formats, I am puzzled by two of your statements. First, that Y.1731 CCMs would ease more vendor's implementations to converge to the 50ms protection timescale. One of the major problems with Y.1731 is the lack of a 100 packet per second rate, forcing the use of 300 packets per second at high resource cost. hemm --- T-REC-Y.1731-200802 --- 7.1.1 CCM (with ETH-CC information) Transmission When ETH-CC is enabled, a MEP periodically transmits CCM frames as often as the configured transmission period. Transmission period can be one of the following seven values: - 3.33ms: default transmission period for protection switching application (transmission rate of 300 frames/second) - 10ms: (transmission rate is 100 frames/second) ^^ --- Even if I'm not a big fan of it I have to say that 100 pps is foressen by Y.1731 (and even by your ID, http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-03, Section 4.1.1) [cut] Y(J)S Ciao FF -Original Message- From: Yaakov Stein [mailto:yaako...@rad.com] Sent: quinta-feira, 8 de Outubro de 2009 8:43 To: Rui Costa; ietf@ietf.org Cc: Adrian Farrel Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard Rui, While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP, and quite understanding the reasoning behind reusing existing formats, I am puzzled by two of your statements. First, that Y.1731 CCMs would ease more vendor's implementations to converge to the 50ms protection timescale. One of the major problems with Y.1731 is the lack of a 100 packet per second rate, forcing the use of 300 packets per second at high resource cost. I feel that 50 ms protection requirements are the best reason NOT to use Y.1731. Second, that the mechanisms in Y.1731 are sufficiently simple to allow some hardwarization. The other main fault with Y.1731 is its fracturing of the capabilities among so many different OAM message types, rather than realizing that there are really only two OAM types (one way and reflecting), with options for various monitoring or measurement functions. If you only need CCMs, yes Y.1731 is easy (but so is any other heartbeat format). Once you want to do CCs, CCs for protection (G.8031/G.8032 require their own), packet loss measurement, and delay measurement, it becomes a nightmare. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
Hi. Some comments about the two possible dispute resolution models -- appeals to the IAB with binding effect or appeals to the IAB with only advisory effect on the RSE and ISE --that I had made in an IAB context never made it onto the list, resulting in Jari being surprised (for which I apologize) and some confusion about what I intended and why. An edited version of those comments (there was mostly-unrelated context around the original notes that isn't repeated here) follows: I don't see much difference between the alternatives of IAB advice to the RFC Editor and IAB mandatory instructions to the RFC Editor in practice, but have a fairly strong pragmatic preference for not having to open, or update, 4846. I believe that, whichever path is chosen, there needs to be a firm requirement that the disagreement and its content be made public if things move beyond a certain, fairly early, point. I also have my usual concern about getting too rigid about this sort of thing -- if the ISE and RSE ignore strong advice from the IAB, we have deeper and more serious problems than one IESG note and will need to deal with those problems in some way. It is probably also desirable that the statement in the draft about attached notes, optional or mandatory, point to the provisions of 4846 that permits withdrawal of a document at any point. In other words, there should never be any question that the ISE or author can respond to a demand for a note by withdrawing the document rather than publishing with the note or applying other remedies. While we've been surrounding this discussion with nice words to the effect that there has never been a real problem and/or that problems have been solved quickly, it isn't entirely true... and the main reason why it is mostly true is that, in recent years, the RFC Editor has backed down rather quickly when such issues have arisen, in part because the issues have been raised in contexts that appeared to involve threats of contractual interference. RFC 4846 was written in part to reestablish the independence of the RFC Editor from unreasonable IESG demands; it would, IMO, be sad to give that up over the principle of mandatory IAB decisions about notes. Although I'm not aware of it happening in recent years, the same ADs who became slightly notorious for holding up IETF work indefinitely because it wasn't to their personal taste (the people for whom the IESG eventually created internal dispute-resolution policies) were sometimes equally aggressive about trying to prevent publication of documents they found distasteful as independent submission RFCs and/or to attach obnoxious notes to them. Of course, all of the occurred in the dark; part of the historical problem here is lack of openness... a situation that continues to this day when the only record of the IESG discussion is a tracker note that there was an objection. As the IAB moves to select an ISE, the choices are presumably not going to be limited to people who will uncritically accept things that the IESG tells them. With a strong and independent ISE, if the IESG imposed a note that the ISE, the Editorial Board, and the authors found really offensive, the ISE would probably decide to not publish the document and might, instead, propose to publish a document for the permanent record that discussed the content of the original, the issues, the proposed IESG note, etc. Again, it would make little difference to that scenario whether the instructions to the RFC Editor were mandatory or not -- the principle and content would be the issue. I assume the IESG would want to attach a note to that document too, although the ISE might then decide to attach additional text explaining that the IESG was invited to write a real commentary or response and decided to resort to note-attaching instead. Of course, good judgment on the part of the ISE would get us into that situation only under the most extreme of circumstances, circumstances that we can reasonably predict will not occur. But, if the circumstances are not real, then the need for a mandatory override procedure isn't either. As some comments to the IETF list have observed, the use of notes is sometimes a lazy and responsibility-avoiding alternate to actually engaging in a fair technical discussion. I would hope that, if an issue like this reaches the IAB, the IAB would insist on such a discussion and that a reasonable summary of it be made public. I don't think that needs to be written down as a requirement. The other piece of this is that the community has decided, multiple times, that we want an Independent Submission process that is actually independent... and, in particular, independent of the IETF and IESG. That consensus is clearly a rough one: each time the topic has come up in the last decade or so we have heard from people who are convinced that the Independent Stream has outlived its usefulness and others who are convinced that it should exist only to serve the
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
John: Speaking pragmatically, I believe that creating a binding inter-stream appeal process probably requires reopening both 4846 and 4844 and, given many of the comments on the IETF list about the previous drafts, would lead to our having to recycle the discussion of the appropriateness of the role of the multiple-stream model and whether the IESG gets a first among equals role or better. I don't believe that repeating that discussion yet again would serve the community well and that is another big argument for the advisory approach. 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 ___ 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
At 04:07 AM 10/7/2009, Henk Uijterwaal wrote: (Personal opinion) On Mon, 5 Oct 2009, Margaret Wasserman wrote: While I do think that the IAOC should be aware of the potential legal implications of where we hold our meetings, I wonder if we are treating China unfairly in this discussion... I agree. So-far, we have always assumed that discussions on crypto as well as writing, testing and using code during the meeting were legal in the country. And if they weren't, we'd assume that the local policy would not notice. China is not different in this respect. Let's parse your statement a bit closer. Actually, so far all of our discussions etc have been legal in the countries in which we've met - or at least we've never been told they are unlawful. Or do you have a specific list of countries in which such discussions or development were prohibited by law or contract? Unlike you I, and I expect many (most) of us would never assume that local policy would not notice. If I were a fiduciary for the IETF I would expect to be sued for failure to exercise due diligence if I took this position and someone noticed. If I were told that a specific act or topic of discussion was illegal or could lead to civil or criminal penalties I would have to evaluate whether that specific act or topic were core for the purpose of the meeting or event. I would then have to make a decision to either refrain from the act or topic (difficult if it was core to the meeting), or (if responsible for the meeting) move the meeting somewhere else. I would not assume I could blithely ignore local law. Hopefully, TPTB are doing this. 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, b) that the penalties for (any of us collectively) breaking the law or terms of the contract could result in meeting termination in addition to any individual penalties. To my knowledge, this is unique to our experience. I haven't seen any comments to the contrary in this discussion thread In the PRC, the certain prohibited acts and topics are acts and topics that have not - to my knowledge - been prohibited either by contract or law at any other venue to which we've been. The acts may be and some of the topics are certainly core to every IETF meeting we've held prior to this and probably prior to every meeting we will hold before any possible future PRC meeting. So no, we're not treating China unfairly in this discussion. We're not holding China to a higher standard, we're questioning - as we must for due diligence - whether the standard to which they want to hold the IETF is too high or too disjoint from the normal set of standards and practices for IETF meetings. Mike Perhaps this is something that we could expect our host to help us determine? The IAOC is in contact with the host about all the issues raised on the list (and then some more). Henk -- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. ___ 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
2009/10/9 Michael StJohns mstjo...@comcast.net So no, we're not treating China unfairly in this discussion. We're not holding China to a higher standard, we're questioning - as we must for due diligence - whether the standard to which they want to hold the IETF is too high or too disjoint from the normal set of standards and practices for IETF meetings. 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: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
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 Unfortunately, our discussions are not so limited... and I'm pretty sure you know that. With respect to the US or for that matter 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. I know of none and I've been around for most of the meetings going back 23 years. At 08:45 PM 10/8/2009, Patrick Suger wrote: 2009/10/9 Michael StJohns mailto:mstjo...@comcast.netmstjo...@comcast.net So no, we're not treating China unfairly in this discussion. We're not holding China to a higher standard, we're questioning - as we must for due diligence - whether the standard to which they want to hold the IETF is too high or too disjoint from the normal set of standards and practices for IETF meetings. 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: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
I think there is general agreement that no normal IETF topic should have to be off limits for any IETF meeting in any location. We can argue about the finer details of what normal implies and we certainly need to establish that such speech would not get us in trouble. All that is happening thanks in part to the dicussion that has taken place on this list. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ 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
At 09:55 PM 10/8/2009, Ole Jacobsen wrote: I think there is general agreement that no normal IETF topic should have to be off limits for any IETF meeting in any location. We can argue about the finer details of what normal implies and we certainly need to establish that such speech would not get us in trouble. To rephrase in a way that you may not agree. We certainly need to establish that the environment of the site, host or country would not cause us or tend to cause us to modify our behavior away from that common to normal IETF meetings. It really isn't about whether or not we might or might not get in trouble, its whether or not the plain language of the laws and contracts describe an environment which is incompatible with the IETF norm. All that is happening thanks in part to the dicussion that has taken place on this list. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ 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 Thu, 8 Oct 2009, Michael StJohns wrote: To rephrase in a way that you may not agree. We certainly need to establish that the environment of the site, host or country would not cause us or tend to cause us to modify our behavior away from that common to normal IETF meetings. It really isn't about whether or not we might or might not get in trouble, its whether or not the plain language of the laws and contracts describe an environment which is incompatible with the IETF norm. I agree. There might be some issues in some countries about what is acceptable behavious OUTSIDE of the meeting room, but we should certainly be able to conduct business as usual in our meetings themselves. (Ignoring for the time being any discussion of plain language and various readings of such). Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 76 messages in the last 7 days. script run at: Fri Oct 9 00:53:02 EDT 2009 Messages | Bytes| Who +--++--+ 1.32% |1 | 26.65% | 194554 | koike.yoshin...@lab.ntt.co.jp 7.89% |6 | 8.27% |60402 | flu...@cisco.com 6.58% |5 | 4.06% |29664 | alexey.melni...@isode.com 5.26% |4 | 4.31% |31496 | john-i...@jck.com 5.26% |4 | 3.98% |29086 | o...@cisco.com 5.26% |4 | 3.18% |23200 | nicolas.willi...@sun.com 5.26% |4 | 2.73% |19929 | d...@dcrocker.net 3.95% |3 | 3.00% |21913 | mstjo...@comcast.net 3.95% |3 | 2.84% |20756 | rich...@shockey.us 3.95% |3 | 2.29% |16694 | b...@estacado.net 2.63% |2 | 2.45% |17865 | rco...@ptinovacao.pt 2.63% |2 | 1.95% |14239 | ruiquan.j...@ties.itu.int 2.63% |2 | 1.68% |12254 | b...@nostrum.com 2.63% |2 | 1.66% |12101 | h...@ripe.net 2.63% |2 | 1.37% | 9993 | dean.wil...@softarmor.com 1.32% |1 | 2.58% |18810 | bernard_ab...@hotmail.com 1.32% |1 | 2.00% |14575 | f...@cisco.com 1.32% |1 | 1.70% |12376 | jonathan.sad...@tellabs.com 1.32% |1 | 1.49% |10876 | denghu...@gmail.com 1.32% |1 | 1.24% | 9024 | hal...@gmail.com 1.32% |1 | 1.13% | 8245 | nar...@us.ibm.com 1.32% |1 | 1.09% | 7938 | yaako...@rad.com 1.32% |1 | 1.08% | 7896 | si...@josefsson.org 1.32% |1 | 1.07% | 7783 | l...@pi.nu 1.32% |1 | 1.05% | 7692 | j...@jck.com 1.32% |1 | 1.01% | 7359 | psu...@gmail.com 1.32% |1 | 0.96% | 7019 | stbry...@cisco.com 1.32% |1 | 0.93% | 6789 | t...@americafree.tv 1.32% |1 | 0.93% | 6755 | d...@xpasc.com 1.32% |1 | 0.92% | 6683 | bob.hin...@gmail.com 1.32% |1 | 0.91% | 6609 | jh...@cmu.edu 1.32% |1 | 0.89% | 6469 | amuha...@nortel.com 1.32% |1 | 0.85% | 6239 | amor...@amsl.com 1.32% |1 | 0.82% | 6023 | m...@sandstorm.net 1.32% |1 | 0.82% | 6005 | francesco.fonde...@gmail.com 1.32% |1 | 0.79% | 5740 | hiro...@wide.ad.jp 1.32% |1 | 0.77% | 5607 | julien.meu...@orange-ftgroup.com 1.32% |1 | 0.77% | 5588 | brian.e.carpen...@gmail.com 1.32% |1 | 0.72% | 5288 | adrian.far...@huawei.com 1.32% |1 | 0.71% | 5210 | wavetos...@googlemail.com 1.32% |1 | 0.67% | 4889 | hous...@vigilsec.com 1.32% |1 | 0.63% | 4586 | ty...@mit.edu 1.32% |1 | 0.57% | 4146 | wei...@tislabs.com 1.32% |1 | 0.52% | 3770 | j...@mercury.lcs.mit.edu +--++--+ 100.00% | 76 |100.00% | 730135 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
