Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
On 10/11/09 8:32 PM, Dave CROCKER wrote: I'm far more concerned that this thread has confused IETF goals and requirements for discussing meeting venues and that many of the postings are moving towards a precedent that the IETF really does not want to set. I strongly agree. I think mixing up what people think is right and what people think is practicable from a logistics perspective confuses two very separate issues that could lead to two separate outcomes, based on the criteria the IAOC uses. I wish people would stick to the logistics argument. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
One more take on rfc3932bis
All, after several private discussions, I'd like to communicate long-standing substantial concerns and conclusions related to the current version of the IESG Procedures for Independent Submission and IRTF Stream I-D, draft-housley-iesg-rfc3932bis-10. Preamble: A strong democracy needs a strong opposition (nearly proverbial; found frequently quoted in The Economist, or refer to http://www.faqs.org/abstracts/Business-international/ Italys-weak-right-hand-a-strong-democracy-needs-a-strong-opposition.html) The IETF (Process and) Stream needs a strong Independent Submission Stream as well. One of the aims of the Headers and Boilerplates effort was to get rid of the necessity for IESG Notes in 'normal' cases. The current draft does mention that in a single sentence in Section 3, below the list of 5 kinds of conclusions possible: The RFC headers and boilerplate is intended to describe the relationship of the document to the IETF standards process [N3]. In | exceptional cases, when the relationship of the document to the IETF | standards process might be unclear, the IESG may provide an IESG note to clarify the relationship of the document to the IETF standards process, such a note is likely to include pointers to related IETF RFCs. [...] Subsequently, the draft now has grown to elaborate on this exceptional case on almost two pages, but it fails to reciprocally establish any means to protect the two streams independent of the IETF stream from many kinds of, say, strange behavior, observed in the past. (Dave Crocker and John Klensin have recalled such observations at an abstract level in their recent postings to this list.) That resulting dis-balance is rather incommensurate. In order to restore some degree of balance, in the spirit of RFC 4648, I suggest to consider the following additions that should help to limit the opportunities for abuse and DoS against these streams: (1) After the clause quoted above, insert: || To ensure the truly exceptional nature of IESG notes, the IESG || sets priorities and rate limits the requests to add IESG notes || to at most 10% (on average) of the drafts submitted to it under || the procedures defined in this document. [[ Notes: a) You might propose another figure than 10% -- arguably this conservative proposal is already beyond what usually would be regarded as 'exceptional'. b) This clause is stated in the form of a self-committment from the IESG; it purposely avoids the installation of additional procedures for supervision. Feedback to the NomCom should suffice in the long term to give the community an opportunity to evaluate and ensure the 'performance' of the IESG w.r.t. this goal. ]] (2) In the 4th-to-last paragraph of Section 3, The IESG will normally complete review within four weeks after notification by the RFC Editor or IRTF. [...] ... insert after the quoted sentence: || If the IESG does not respond within ten weeks, the ISE or the || IRTF, respectively, can firmly assume that conclusion #1 holds. [[ Note: Despite handwaving arguments presented, it should be worth using precise terms to avoid confusion, and denote the 'gatekeeping' entities of the streams with the names now assigned to them. So please replace RFC Editor by the more precise Independent Submission Editor (ISE) wherever that RFC Editor 'function' is intended to be denoted -- it most likely will be an independent person or team soon. In this draft, almost all instances of RFC Editor do not refer to the (abstract) umbrella institution still assigned that name, nor to the RSE (which in practice most likely will colloquially still be called the RFC Editor in the future), but to the ISE. ]] (3) The intent of conclusion #3 was, and is, to give the IETF 'protected' time to bring a starting or ongoing effort to success. Failure of the IETF (not too rarely not only on the WG level!) to achieve that success within a reasonable time span should not be able to block a document forever. As any other measures of suspension codified in the IETF process, this decision should have a 'built-in' time limit, and it should not last indefinitely by default. Here's my proposal to correct that: After the paragraph in Section 3 starting with The last two responses are included respectively, [...] insert a new paragraph establishing a timout rule prohibiting indefinite stalling of documents by conclusion #3; for instance: || In the case of the third conclusion, lack of progress in the IETF || should not be able to block a document forever. If the IETF does || not arrive at bringing the work denoted as potentially disrupted || to a state where publication is granted or extremely likely, || within a period of two years from the time of the conclusion || suspending the Independent Submisison or IRTF stream document, || the ISE or IRTF, respectively, may decide to forward
Re: Request for community guidance on issue concerning a future meetingof the IETF
On Sun, 2009-10-11 at 15:31 -0700, Dave CROCKER wrote: Cullen Jennings wrote: I carefully stayed away from social policy issues 1) What is political speech in China? ... 2) Are there any special rules about publishing and broadcasting? I ... 5) When discussing what I think of as technical issues, many participants regularly treat Taiwan and PRC as two different countries ... Could any discussions like this be viewed as political speech? What are the rules on this? This is your version of staying away from social policy? If it is, I suspect that what is first needed are lessons in the nature of social and political policy. I suspect you -- and most of the rest of us -- can't give a definitive answer to these questions for any other venue the IETF has ever met in. As a small example, I doubt many of us have a meaningful clue about the detailed impact of the US's Patriot Act as it changed basic freedoms's for citizens, nevermind non-citizens. Really, Cullen, it's difficult to overemphasize just how basic a mistake it is for us to pursue your questions. I don't think it's helpful for you to repeatedly try to shut down attempts to get answers to questions that many people on the list have repeatedly said that they think are relevant and important. I don't think that Cullen has asked for opinions from anyone on whether the rules in China are right or wrong - that would certainly be discussing social policy. What he has asked for is discussion of how they will impact the normal functioning of an IETF meeting, and I for one agree that the answers are important in that current context. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
Scott Lawrence wrote: I don't think it's helpful for you to repeatedly try to shut down attempts to get answers to questions that many people on the list have repeatedly said that they think are relevant and important. Sure it is. It is specifically helpful. The questions constitute a denial of service attack on IETF operations. In terms of principle, I and others have pointed out the basic flaw in asking these types of question. The mere fact of having some questions does not justify asking them and most certainly does not justify requiring that they be answered. In terms of pragmatics, you are missing the fact that there is an infinite number of questions that one can ask and that it is not feasible to answer them, nevermind require that they be answered. In terms of management structure, these questions alter the historical separation of labor that has existed in the IETF. Although it can be entirely reasonable to make changes to management structure, this needs to be pursued as a matter of policy and not ad hoc -- and by the way nationally biased -- opportunistic curiosity. Hence, the implications of changing policy need to be addressed explicitly, with an eye for later, potentially undesirable effects. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
On Oct 12, 2009, at 8:44 AM, Dave CROCKER wrote: The questions constitute a denial of service attack on IETF operations. I really don't think so. I don't even think there's a denial of service effect, regardless of intent. The community was asked for feedback about meeting in the PRC given what appears to be some pretty problematic text in the hotel contract. I don't think that questions about what that text actually might mean in practice are inappropriate or disruptive. To the contrary - I think it's quite clear from the discussion that there's not a common understanding of the contract terms, or, for that matter, even a common understanding of the questions that were asked in the first place. Personally, I don't know what I think although I'm leaning towards thinking it's a bad idea if a hotel employee can shut the meeting down if they don't like the content or what some random attendee says in the hallway. But - and this is a big but - I don't know if I'm understanding the contract correctly. And because of my own lack of clarity around the terms of the contract I'm grateful for Cullen's questions, which I think will help crystallize much of what's under discussion. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
+1 I think issues have been raised that should not be relevant and that should be considered, if at all, as part of some other question or issue. But most of the recent ones, including Cullen's questions, seem very much in line with trying to understand the question the IAOC decided to ask for as to give an informed answer to it. john --On Monday, October 12, 2009 08:55 -0800 Melinda Shore sh...@arsc.edu wrote: On Oct 12, 2009, at 8:44 AM, Dave CROCKER wrote: The questions constitute a denial of service attack on IETF operations. I really don't think so. I don't even think there's a denial of service effect, regardless of intent. The community was asked for feedback about meeting in the PRC given what appears to be some pretty problematic text in the hotel contract. I don't think that questions about what that text actually might mean in practice are inappropriate or disruptive. To the contrary - I think it's quite clear from the discussion that there's not a common understanding of the contract terms, or, for that matter, even a common understanding of the questions that were asked in the first place. Personally, I don't know what I think although I'm leaning towards thinking it's a bad idea if a hotel employee can shut the meeting down if they don't like the content or what some random attendee says in the hallway. But - and this is a big but - I don't know if I'm understanding the contract correctly. And because of my own lack of clarity around the terms of the contract I'm grateful for Cullen's questions, which I think will help crystallize much of what's under discussion. Melinda ___ 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: Request for community guidance on issue concerning a future meetingof the IETF
+1 Cullen is not inquiring after social policy, he's asking what the practical constraints are likely to be if there is a meeting in China. This is a sensible question, worthy of a thoughtful, well-researched response. I suspect you -- and most of the rest of us -- can't give a definitive answer to these questions for any other venue the IETF has ever met in. As a small example, I doubt many of us have a meaningful clue about the detailed impact of the US's Patriot Act as it changed basic freedoms's for citizens, nevermind non-citizens. The question isn't whether someone on this list has a definitive answer -- or anyone, really. The request was for appropriate due diligence to be done to estimate some parameters that are right now very uncertain. One could perform a similar analysis for other venues, but in most places where the IETF has met, the level of initial uncertainty has been much lower due to the relative clarity of precedent in constitutional, legislative, and judicial terms. (P.S.: Could we make a corollary to Godwin's Law for the PATRIOT Act?) --Richard Scott Lawrence wrote: On Sun, 2009-10-11 at 15:31 -0700, Dave CROCKER wrote: Cullen Jennings wrote: I carefully stayed away from social policy issues 1) What is political speech in China? ... 2) Are there any special rules about publishing and broadcasting? I ... 5) When discussing what I think of as technical issues, many participants regularly treat Taiwan and PRC as two different countries ... Could any discussions like this be viewed as political speech? What are the rules on this? This is your version of staying away from social policy? If it is, I suspect that what is first needed are lessons in the nature of social and political policy. I suspect you -- and most of the rest of us -- can't give a definitive answer to these questions for any other venue the IETF has ever met in. As a small example, I doubt many of us have a meaningful clue about the detailed impact of the US's Patriot Act as it changed basic freedoms's for citizens, nevermind non-citizens. Really, Cullen, it's difficult to overemphasize just how basic a mistake it is for us to pursue your questions. I don't think it's helpful for you to repeatedly try to shut down attempts to get answers to questions that many people on the list have repeatedly said that they think are relevant and important. I don't think that Cullen has asked for opinions from anyone on whether the rules in China are right or wrong - that would certainly be discussing social policy. What he has asked for is discussion of how they will impact the normal functioning of an IETF meeting, and I for one agree that the answers are important in that current context. ___ 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 P RC. Was: Re: Request for communityguidance on i ssue concerning a future meeting of the IETF
Hi Tian, I think the question here is what makes for a politically sensitive discussion. In places where IETF meetings have historically been held, there has been a lot of distance between technical topics and political topics. In the US and much of Europe, for example, discussions of techniques for avoiding firewalls or anonymizing traffic are largely considered technical, not political. (Although people might have political reasons for discussing these topics.) The concern is that in the Chinese context, the sets of technical and political topics could be closer, if not overlapping -- that some technical topics might not be overtly political, but might be close enough to cause trouble. --Richard jiangt wrote: Dear Richard and Ole, I'm an engineer from China. I like to check IETF mailing list and try to keep up with the development trend of IETF. I think that politically sensitive discussions possiblely bring troubles to the meeting, if any. But I do not know why IETF engineers worry about someone to make a political speech in a **technical** meeting and I want to know who plan to make such a speech? BTW, I'm not interested in such a speech when I attend IETF meeting, how about U? Tian -邮件原件- 发件人: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] 代表 Richard Barnes 发送时间: 2009年10月10日 8:53 收件人: Ole Jacobsen 抄送: Theodore Tso; Henk Uijterwaal; IETF-Discussion list 主题: Re: Legality of IETF meetings in PRC. Was: Re: Request for communityguidance 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 答复: Legality of IETF meetings in P RC. Was: Re: Request for communityguidance on i ssue concerning a future meeting of the IETF
You said: In the US and much of Europe, for example, discussions of techniques for avoiding firewalls or anonymizing traffic are largely considered technical, not political. (Although people might have political reasons for discussing these topics.) The concern is that in the Chinese context, the sets of technical and political topics could be closer, if not overlapping -- that some technical topics might not be overtly political, but might be close enough to cause trouble. This is only my PERSONAL opinion and does not constitute legal or international advice etc, but: Discussion of the topics you cite in your example would be perfectly fine and not cause any trouble. As I've said previously, our proposed hosts are long-standing contributors and members of the IETF community. They know our ways and if they seriously believed that we'd be walking into a danger zone by having normal IETF topics on the agenda they would not have invited us. In due course, the IAOC will be making a statement on our decisions about this meeting. As Ray said, this is expected to occur before IETF 76. Until then, I am going to try to limit posting on this topic since I'm already ranking too high on the Narten score :-) Feel free to ask me about IETF 76 logistics, particularly on the 76attend...@ietf.org list. Cheers, 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: Request for community guidance on issue concerning a future meetingof the IETF
On Mon, Oct 12, 2009 at 09:44:58AM -0700, Dave CROCKER wrote: The questions constitute a denial of service attack on IETF operations. In terms of principle, I and others have pointed out the basic flaw in asking these types of question. The mere fact of having some questions does not justify asking them and most certainly does not justify requiring that they be answered. In terms of pragmatics, you are missing the fact that there is an infinite number of questions that one can ask and that it is not feasible to answer them, nevermind require that they be answered. Historically, the general culture of the IETF is that if people have a good question, it's always in scope to raise it. After all, as an engineering organization, our goal is protocols that _work_, and not just following Policies and Procedures. In fact, I'd like to think that part of the IETF culture which makes things different with say, ISO. With ISO, even if the protocol is fatally flawed, if it's in wrong part of the process, they'll go ahead and approve the standard just because the right number of national bodies had voted on it. With the IETF, even at last call, if someone can raise a valid technical objection that hasn't been previously considered, the IESG is supposed to consider that objection. If they don't, that can be a valid matter to appeal. So it seems kind of out of the IETF culture to say, this question is shouldn't be answered because it didn't come from the wrong part of the structure. That's like saying that a Management AD can't raise a question about security because they aren't from the Security Area. It's not considered a denial of service attack. It's considered a valid issue that should be considered. Ultimately, of course, there are checks and balances to make sure it's not a question that has already been asked and answered, and whether or not the question is valid or not. But we generally don't say, la la la la la --- it's not even right to ask the question because you're not from the right area. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
At 10:29 AM -0700 10/9/09, SM wrote: ... 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. I think may is the right term here. But, if the IESG chooses to assert this prerogative, I would like to see the note inserted, without the need for RFC Editor concurrence. 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. When the site closed, do you believe that all of the material published there will become inaccessible, not archived anywhere? I doubt that. 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. The status quo does not mandate that the RFC Editor and the IESG agree; it allows the RFC Editor to make a unilateral decision to ignore an IESG note. So, I don't agree with the second part of your statement above. I do agree that the change diminishes the independence of the RFC Editor. 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
On Oct 7, 2009, at 2:07 AM, Henk Uijterwaal wrote: 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. Henk, just clarify question. I assume you meant police not policy in the sentence above? Is that correct. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Requesting a Non Smoking Room at the IETF 76 Overflow Properties
If you want a non smoking sleeping room and you are staying at one of the IETF 76 overflow properties, you will need to make your request a via a separate email. When you receive the email confirmation of your initial reservation, you will see at the very end of the email a section titled Inquiry Desk -- this section includes a contact email address. Please forward your confirmation email, and a short statement indicating your preference for a non smoking room, to this address. Please also copy me, as I would like to track how many such requests are made. Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IETF and the SmartGrid
Is there any planned ad-hoc meeting/session related to this topic in Hiroshima meeting? Peny On Tue, Oct 6, 2009 at 5:47 AM, Fred Baker f...@cisco.com wrote: Thanks. You already know this, as does Russ Housley, but I'll say it out loud for others to hear. At the third NIST workshop on the Smart Grid, which was the week following the IETF meeting, several IETFers were invited by David Su of NIST to a workshop on the role of the Internet Architecture in the Smart Grid. He specifically asked for a document that could be used to discuss and describe the Internet Architecture, specifically to support the profiling (eg, subseting) of its architecture for the purpose. To that end, I started http://tools.ietf.org/html/draft-baker-ietf-core Core Protocols in the Internet Protocol Suite, Fred Baker, 3-Oct-09, draft-baker-ietf-core-03.txt The initial document essentially described the protocols appropriate to a host; at the request and behest of several commentators, I have since added a brief description of unicast and multicast routing, QoS, address allocation and assignment (DHCP and ND), NTP, DNSSEC, SIP, the ISO Transport Service Interfaces (necessary for ACSE, which is used in the Smart Grid) and something of the business architecture of the Internet and therefore firewalls, NATs, and VPNs. I have in the can a version that puts in references for MPLS, and given that NIST is asking about calendaring and SNMP will likely include a few sentences on those. I'm trying to walk what is at best a grey line; The things that are at the Internet Architecture's absolute core, at least to my mind, are described in RFCs 1122, 1123, and 1812. However, NIST is asking about the place of more things (like calendaring and timekeeping) and other possible users of the document are also asking for things that are more core to the business than the architecture, like NATs and MPLS. So I am trying to describe things that are core, and also answer useful questions about less-core things, all without trying to provide a list of all 1574 proposed standards, 89 draft standards, and 82 standards. Individuals who have noticed the draft have commented; folks who care should also do so. I have asked the IESG for directorate reviews, but have not gotten anything from any directorates. As you say, NIST is requesting commentary on http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf. Those of us that work for US corporations or educational institutions would likely be wise to be involved in corporate reviews and replies, as that is how most review of this type comes back. The exact structure to reply in has not yet been announced, but I would imagine that will be remedied soon. On Oct 5, 2009, at 2:20 PM, Richard Shockey wrote: The general internet community needs to be aware of activities in North America that directly relate to the use of IETF protocols in the Electric Utility industry. This activity is generally referred to as the SmartGrid. Though the issues immediately deal with technical and policy decisions in the US and Canada, the SmartGrid concept is gaining significant momentum in Europe and Asia as well. http://www.smartgrids.eu/ http://en.wikipedia.org/wiki/Smart_grid#Countries The SmartGrid has many definitions but as a practical matter it is a substantial re-architecture of the data communications networks that utilities use to maintain the stability and reliability of their power grids. Many of the requirements for the SmartGrid in North America came out of the 2003 North East power outage which demonstrated a substantial lack of investment in Utility IT systems. http://www.ferc.gov/EventCalendar/Files/20040915141105-blackout.pdf Of particular note, is the desire by utilities to extend the reach of their communications networks directly to the utility meter and beyond ultimately into the customer premise itself. This is generally referred to as the Advanced Meter Interface (AMI). One of the use cases driving this requirement is the next generation of plug-in hybrid electric vehicles. The utilities, correctly IMHO, want to precisely control the timing of how these vehicles are recharged so not to create a unique form of DOS attack and take out the grid when everyone goes home at night. This is a principal use case in 6lowpan ( ID below ). Increasingly energy flows are becoming bi-directional creating needs for more computational intelligence and capability at the edge. What is going on? Why should the IETF community care? The United States Government, as part of the Energy Independence and Security Act of 2007 gave the National Institute of Standards and Technology ( NIST ) principal responsibility to coordinate development of a framework that includes protocols and model standards for the SmartGrid. http://www.nist.gov/smartgrid/ After several meetings sponsored by NIST in recent months, NIST
Re: The IETF and the SmartGrid
On Oct 12, 2009, at 5:18 PM, Peny Yang wrote: Is there any planned ad-hoc meeting/session related to this topic in Hiroshima meeting? Well, ROLL and 6lowpan are relevant. http://trac.tools.ietf.org/bof/trac/wiki and specifically http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 has a BOF called 6lowapp that is likely equally relevant, which is to say not designed specifically for the smart grid but potentially usable there. At this point, I'm not sure that the IETF has decided that the Smart Grid needs anything we haven't already given it in the Internet Architecture. It might, but I for one don't know yet what it would be. Perhaps a reliable multicast transport, perhaps a route me differently flag in IPv6 (which multipath TCP could also use), perhaps permission to send from a multicast group address, perhaps something else. At this point I don't think we honestly know what would help them. Looks like we may have a bar BOF. ___ 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
Cullen Jennings wrote: On Oct 7, 2009, at 2:07 AM, Henk Uijterwaal wrote: 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. Henk, just clarify question. I assume you meant police not policy in the sentence above? Is that correct. That is correct. 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
Document Action: 'Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions' to Informational RFC
The IESG has approved the following document: - 'Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions ' draft-ietf-opsawg-operations-and-management-09.txt as an Informational RFC This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-management-09.txt Technical Summary New protocols or protocol extensions are best designed with due consideration of functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents defining new protocols or protocol extensions, about covering aspects of operations and management that should be considered. Working Group Summary There was consensus in the working group to publish this document. Document Quality The document was reviewed by a number of experts with operational and management experience. An IETF Last Call was run and comments received during the Last Call were incorporated in the final version. Personnel Scott Bradner is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. RFC Editor Note 1. In Section 1.2: OLD: This document discusses the importance of considering operations and management by setting forth a list of guidelines and a checklist of questions to consider, NEW: This document discusses the importance of considering operations and management by setting forth a list of guidelines and a checklist of questions to consider (see Appendix A), 2. In Section 7 s/Adrian Farrell/Adrian Farrel/ 3. In Section 1.6: OLD: This document is a set of guidelines based on current practices of protocol designers and operators. This document does not describe requirements, so the key words from RFC2119 have no place here. NEW: This informational document is a set of guidelines based on current practices of **some** protocol designers and operators. This document is biased toward router operations and management and some advice may not be directly applicable to protocols with a different purpose, such as application server protocols. This document **does not** describe interoperability requirements, so the capitalized key words from RFC2119 do not apply here. 4. Add in Section 4: This document does not describe interoperability requirements, but rather describes practices that are useful to be followed in dealing with manageability aspects in the IETF documents, so the capitalized keywords from RFC2119 do not apply here. Any occurrence of words like 'must' or 'should' needs to be interpreted only in the context of their natural English language meaning. 5. In section 1.5: OLD: SNMP [RFC3410], SYSLOG [RFC5424], RADIUS [RFC2865], DIAMETER [RFC3588], NETCONF [RFC4741], IPFIX [RFC5101]. NEW: Simple Network Management Protocol - SNMP [RFC3410], SYSLOG [RFC5424], Remote Authentication Dial In User Service - RADIUS [RFC2865], DIAMETER [RFC3588], Network Configuration Protocol - NETCONF [RFC4741], IP Flow Information Export - IPFIX [RFC5101]. 6. in Section 1.4 OLD: One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410] and COPS Usage for Policy Provisioning (COPS-PR) [RFC3084], and it was recommended that the IETF explore an XML-based Structure of Management Information, and an XML-based protocol for configuration. NEW: One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410] and Common Open Policy Service (COPS) Usage for Policy Provisioning (COPS-PR)[RFC3084], and it was recommended that the IETF explore an XML-based Structure of Management Information, and an XML-based protocol for configuration. 7. in Section 3.1: OLD: Other Standard Development Organizations (e.g. DMTF, TMF) NEW: Other Standard Development Organizations (e.g. the Distributed Management Task Force - DMTF, the Tele-Management Forum - TMF) 8. In Section 3.3.2: OLD: Would some threshold-based mechanisms, such as RMON events/alarms or the EVENT-MIB, be useable to help determine error conditions? NEW: Would some threshold-based mechanisms, such as Remote Monitoring (RMON) events/alarms or the EVENT-MIB, be useable to help determine error conditions? 9. In Section 3.4: OLD: There are two parts to this: 1. An NMS system could optimize access control lists (ACLs) for performance reasons NEW: There are two parts to this: 1. A Network Management System (NMS) could optimize access control lists (ACLs) for performance reasons
Document Action: 'IPv4 Address Blocks Reserved for Documentation' to Informational RFC
The IESG has approved the following document: - 'IPv4 Address Blocks Reserved for Documentation ' draft-iana-ipv4-examples-02.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iana-ipv4-examples-02.txt Technical Summary Several IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. RFC 1166 reserves the first of these address blocks (192.0.2.0/24). Other address blocks have recently been allocated for examples, primarily to ease the writing of examples involving addresses from multiple networks. Working Group Summary This document is not the product of any IETF WG. Protocol Quality The document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Updated IANA Considerations for Diameter Command Code Allocations' to Proposed Standard
The IESG has approved the following document: - 'Updated IANA Considerations for Diameter Command Code Allocations ' draft-ietf-dime-diameter-cmd-iana-01.txt as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-01.txt Technical Summary The Diameter Base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands, i.e. messages used by Diameter applications, and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has lead to questionable design decisions by other Standards Development Organizations which chose to define new applications on existing commands rather than asking for assignment of new command codes for the pure purpose of avoiding bringing their specifications to the IETF. In some cases interoperability problems were causes as an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of Diameter application with the Diameter commands offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. Working Group Summary This document is the product of the DIME working group. The extensibility rules of Diameter have been investigated by a design team and the alignment of policy for extending Diameter applications and Diameter commands has been agreed. Document Quality This document focuses on the description of the allocation policy change in the IANA consideration section and has been discussed for some time. Personnel Victor Fajardo is the document shepherd for this document. Ron Bonica is the responsible AD. RFC Editor Note Section 3 content should be modified as follows: OLD This document modifies the IANA allocation of Diameter Command Codes in relationship to RFC 3588. This process change itself does not raise security concerns, but the command codes space is split into a standards commands space and a vendor-specific command codes space, the later being allocated on a First Come, First Served basis by IANA at the request of vendors or other standards organizations. Whenever work gets delegated to organizations outside the IETF there is always the chance that fewer security reviews are conducted and hence the quality of the resulting protocol document is weaker compared to the rather extensive reviews performed in the IETF. The members of the DIME working group are aware of the tradeoff between better specification quality and the desire to offload work (e.g., to reduce the workload in the IETF) to other organizations. Other organizations are therefore made responsible for the quality of the specifications they produce. NEW This document modifies the IANA allocation of Diameter Command Codes in relationship to RFC 3588. This process change itself does not raise security concerns, but the command codes space is split into a standards commands space and a vendor-specific command codes space, the later being allocated on a First Come, First Served basis by IANA at the request of vendors or other standards organizations. Whenever work gets delegated to organizations outside the IETF there is always the chance that security reviews are conducted in different manner and the criteria and style of the reviews are different than the reviews performed in the IETF. The members of the DIME working group are aware of the risks involved in using different security and quality review processes and the desire to offload work (e.g., to reduce the workload in the IETF) to other organizations. Other organizations are therefore made responsible for the quality of the specifications they produce. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5333 on IANA Registration of Enumservices for Internet Calendaring
A new Request for Comments is now available in online RFC libraries. RFC 5333 Title: IANA Registration of Enumservices for Internet Calendaring Author: R. Mahy, B. Hoeneisen Status: Standards Track Date: October 2009 Mailbox:ro...@ekabal.com, ber...@ietf.hoeneisen.ch Pages: 8 Characters: 13945 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-enum-calendar-service-04.txt URL:http://www.rfc-editor.org/rfc/rfc5333.txt This document registers Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV). [STANDARDS TRACK] This document is a product of the Telephone Number Mapping 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
