Re: IETF privacy policy - update
my experience suggests that IETF WG mailing lists and participation lists in meetings will be used as evidence in litigation related to whether an individual or the organization which sponsored that individidual met the obligation of the relevant IETF patent policy now http://www.ietf.org/rfc/rfc3979.txt my concept of an SDO that is not open is one that limits membership and disallows membership for some party with a potential material interest to benefit the interests of the existing members. What is the specific reference that ITU has made w/r to IETF not being open? I would like to see it. Best Regards, George T. Willingmyre, P.E. President, GTW Associates 1012 Parrs Ridge Drive Spencerville, MD 20868 USA 1.301.421.4138 - Original Message - From: Fred Baker f...@cisco.com To: Melinda Shore sh...@arsc.edu Cc: Sam Hartman hartmans-i...@mit.edu; Paul Hoffman paul.hoff...@vpnc.org; IETF-Discussion list ietf@ietf.org Sent: Thursday, July 08, 2010 4:24 PM Subject: Re: IETF privacy policy - update On Jul 8, 2010, at 1:18 PM, Melinda Shore wrote: On Jul 8, 2010, at 12:08 PM, Fred Baker wrote: Boy, would they dispute that. ITU has claimed that the IETF is not an open organization because a government cannot join it. Most membership organizations, RIPE, being an example, have a definition of how someone can become a member (members of RIPE are companies and pay a fee), and are considered open to that class of membership. But the IETF isn't a membership organization - isn't that at least in part what's meant by open, and why at least in part we don't have voting (in theory)? We don't have voting because we don't have members, yes. Definitions of open vary, and boil down to a statement of what kind of actor an organization is open to. IETF is open to individuals. ___ 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: IETF privacy policy - update
On 08/07/2010 22:24, Fred Baker wrote: On Jul 8, 2010, at 1:18 PM, Melinda Shore wrote: On Jul 8, 2010, at 12:08 PM, Fred Baker wrote: Boy, would they dispute that. ITU has claimed that the IETF is not an open organization because a government cannot join it. Most membership organizations, RIPE, being an example, have a definition of how someone can become a member (members of RIPE are companies and pay a fee), and are considered open to that class of membership. Wait... There are two organizations: RIPE and RIPE NCC. RIPE is an open group of people interested in IP based networks in Europe and surrounding areas. There is no formal membership, work is done by volunteers, anybody who is interested can join the mailing lists and participate, anybody who pays the meeting fee can attend the meeting and participate there. From an organizational point of view, it is pretty similar to the IETF. RIPE NCC is an organization established to do whatever ISP's and other network providers have to organize as a group, even though they are competitors, on a professional basis. It is a membership organization open to everybody who meets the criteria (which is essential: run a network). The RIPE NCC has an annual meeting, where the members decide on what activities will be carried out in the next year. This meeting is open to members only, which makes a lot of sense as the members also write the checks to cover the costs. And to answer the original question: yes, if you register for the RIPE or RIPE NCC meetings, your name will appear on the public attendees list. 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 -- I confirm today what I denied yesterday.Anonymous Politician. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On 9 jul 2010, at 08.06, Henk Uijterwaal wrote: On 08/07/2010 22:24, Fred Baker wrote: On Jul 8, 2010, at 1:18 PM, Melinda Shore wrote: On Jul 8, 2010, at 12:08 PM, Fred Baker wrote: Boy, would they dispute that. ITU has claimed that the IETF is not an open organization because a government cannot join it. Most membership organizations, RIPE, being an example, have a definition of how someone can become a member (members of RIPE are companies and pay a fee), and are considered open to that class of membership. Wait... There are two organizations: RIPE and RIPE NCC. RIPE is an open group of people interested in IP based networks in Europe and surrounding areas. There is no formal membership, work is done by volunteers, anybody who is interested can join the mailing lists and participate, anybody who pays the meeting fee can attend the meeting and participate there. From an organizational point of view, it is pretty similar to the IETF. RIPE NCC is an organization established to do whatever ISP's and other network providers have to organize as a group, even though they are competitors, on a professional basis. It is a membership organization open to everybody who meets the criteria (which is essential: run a network). The RIPE NCC has an annual meeting, where the members decide on what activities will be carried out in the next year. This meeting is open to members only, which makes a lot of sense as the members also write the checks to cover the costs. And to answer the original question: yes, if you register for the RIPE or RIPE NCC meetings, your name will appear on the public attendees list. Thanks Henk. Let me just add that the policies and rules RIPE NCC follow are developed in the open RIPE process. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: wanted: your old NAT home router
Hi, a quick status update. We now have received over 100 donated home gateways, plus a DSLAM. The students are on their summer break, after which we'll start running a significantly expanded set of tests over this much larger population of devices. Many of yo have donated boxes and suggested more experiments and better ways of performing our current tests - thank you! In case you are attending IETF-78 in Maastricht and would like to donate a home gateway, simply bring it. (Or contact me now for shipping details; no cost to you.) We're especially interested in devices from outside the EU and North America, or any other model we may not have yet (see http://fit.nokia.com/lars/tmp/2010-hgw-study-devices.txt). And we're still lacking a CMTS for testing cable modems... See you in Maastricht, Lars On 2010-6-2, at 18:36, Lars Eggert wrote: Hi, FYI, a first report with test results for 34 devices is available at http://fit.nokia.com/lars/tmp/2010-hgw-study.pdf. Slides that summarize the results are at http://fit.nokia.com/lars/tmp/2010-hgw-study-slides.pdf. We have received another 30-odd devices as donations, which we'll add to the testbed and include in a follow-up study. If you have an unused, spare home gateway to donate to this effort, please contact us at nat-st...@fit.nokia.com. We're also interested in obtaining a DSLAM and a CMTS. Thanks, Lars On 2010-4-29, at 12:34, Lars Eggert wrote: Hi, for a measurement study done together with Markku Kojo's team at the University of Helsinki, we're looking to collect as many different NAT home routers as possible. If you have an old clunker lying around somewhere, please contact me off-list. I'll cover shipping via DHL. Feel free to forward this email as you see fit. The boxes will find a permanent home at the University of Helsinki. Study results will be published openly. The intent is that this collection become a resource for the community to be shared for future studies. Caveat: The boxes should NAT between Ethernet interfaces - we don't have DSL or cable access equipment in the lab setup at the moment. Thanks, Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On Jul 8, 2010, at 11:06 PM, Henk Uijterwaal wrote: RIPE is an open group of people interested in IP based networks in Europe and surrounding areas. There is no formal membership, work is done by volunteers, anybody who is interested can join the mailing lists and participate, anybody who pays the meeting fee can attend the meeting and participate there. From an organizational point of view, it is pretty similar to the IETF. This is getting fairly far afield of the topic, but let me explain where I'm coming from. I did a google search for privacy statements, and came to http://labs.ripe.net/node/49. Poking around, I found http://www.ripe.net/membership/gm/gm-may2010/evoting-announcement.html, which is about RIPE NCC membership, attendees, and voting. I also found another statement that said it was from RIPE (as opposed to the RIPE NCC) and listed members, voting, and attendees, but now I'm not dredging that up. To bring matters back to the topic, the discussion was on Alissa's draft, and I was looking for comparable privacy statements to compare. My question was is this a reasonable statement? Are there things it could have said more simply? Are there things it left out? Are there things it should not have included? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
Hi Bob, just a very quick reaction to your mail: ~snip~ I have issues with the Introduction. The first sentence says: In keeping with the goals and objectives of this standards body, the IETF is committed to the highest degree of respect for the privacy of IETF participants and site visitors. This makes it sound like the highest priority of the IETF is Privacy. I don't think this is true as I described above. The vast majority of what the IETF does in Public. There is very little that is Private. The IETF is careful about what needs to be kept private and does not disclose it. The Fair Information Practices are a set of principles most of us are quite likely to believe in, such as (copied from the Alissa's draft): o Collection Limitation: There should be limits to the collection of data about people. o Data Quality: Personal data should be accurate, complete, up-to- date, and relevant to the purposes for which it was collected. o Purpose Specification: The purpose of collecting personal data should be specified in advance of collection. o Use Limitation: Personal data should only be used for the purposes for which it was collected. o Security: Personal data should be protected by reasonable security safeguards against unauthorised access, use, and disclosure. o Openness: Practices and policies with respect to personal data should be open and transparent. o Individual Participation: Individuals should have choice, access, correction, and redress rights with respect to their data. o Accountability: Those that collect and use data should be accountable for complying with the above principles. When you read privacy then replace it with these principles and everything makes much more sense to you. As an example, imagine some researchers doing some interesting network testing and collect data that travels over the IETF network then these principles say that you should be transparent in what you do, you should tell people what you collect and why, etc. I think that this is something we want people to do. And yes we have researchers looking into the traffic, people storing all sorts of data, etc. I don't think we have anything to hide. It would be a bad sign to say that the IETF is so special that we don't need to follow privacy principles (even if we try to consider privacy in the development of our protocols and tell other SDOs that it is really important to do so). Ciao Hannes PS: If you do not know about the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data then maybe some other folks have not heard about these privacy principles either. Maybe we should add privacy to our Sunday education program. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On Fri, Jul 9, 2010 at 6:45 PM, Fred Baker f...@cisco.com wrote: To bring matters back to the topic, the discussion was on Alissa's draft, and I was looking for comparable privacy statements to compare. My question was is this a reasonable statement? Are there things it could have said more simply? Are there things it left out? Are there things it should not have included? Would a pointer to the W3C's help? It is actually a collection, found here: http://www.w3.org/Consortium/Legal/privacy-statement-2612 regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
More on privacy: The Role of the IETF in Improving Privacy on the Internet
Hi all, thanks to Alissa everyone is now focused on privacy. I thought it would be a good opportunity to share a short writeup with you; it has the title The Role of the Internet Engineering Task Force (IETF) in Improving Privacy on the Internet. The article can be downloaded from http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-32.pdf. We (Jon, Bernard, and Karen) wrote this short position paper as a contribution for the W3C Workshop on Privacy for Advanced Web APIs. More about the workshop can be found here: http://www.w3.org/2010/api-privacy-ws/. A little bit of background: Some of us worked in the GEOPRIV working group and had been exposed to the topic of privacy for years already. Over time we got a better understanding of it, also with the help of privacy experts like John Morris and Alissa. When the W3C then started their work on a so-called Geolocation API many of us had expressed concerns about how privacy is addressed in the design of that protocols. We got the impression that users would be exposing their location in surprising ways. We weren't, however, able to convince certain people involved in the design of the protocol and the Geolocation API got implemented and deployed. As deployment investigations later showed (see references in the paper) the privacy properties being provided in the wild weren't favorable for users. With the ongoing work on the Device API in the W3C there is even more risk of getting things wrong since this work essentially allows to expose your camera, microphone, contact list, storage, etc. via your web browser to Web sites (who sent you the right JavaScript code). Now, it seems that even the last few folks have realized that there might be a privacy issue in the air. Hence, the W3C schedule a workshop with the focus on these APIs. We looked into the work various IETF groups did in the area of privacy and came to the conclusion that we do actually consider privacy in our protocol design. The paper highlights a couple of cases. We do not have a systematic approach of doing so but the structure of the IETF as an organization, the processes we have (with various levels of reviews), and the wide expertise allow us to catch or document potential privacy unfriendliness. We (the IAB) would like to figure out what the IETF and the IRTF can do to provide better privacy protection and where our influence ends. To do so we need your help. Your feedback to the article and the topic overall is appreciated. Ciao Hannes (on behalf of the author team) PS: Note that the article is not an IAB document and represents only the opinion of the authors. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Privacy Terminology
Hi all, I mentioned the position paper for the W3C Workshop on Privacy for Advanced Web APIs already in my last mail. Within the IAB we had planned a series of activities related to privacy and here is another one: Terminology When you look through various IETF documents you will notice that the term privacy is used here and there but often the meaning varies a lot. If you only look at the privacy related articles in newspapers and magazines you will notice the breadth of the topic. Having terminology to work with is quite crucial to avoid talking past each other. Here is an initial submission for privacy terminology: https://wiki.tools.ietf.org/id/draft-hansen-privacy-terminology-00.html Marit and Andreas had worked on this document for about 10 years outside the IETF and it is frequently cited by those working in the privacy area. We thought it would make sense to bring this work to the IETF, to discuss it in a wider audience, and to produce a stable reference. Again, feedback is appreciated. Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
[ fwiw, i am not bothered if some folk well-versed in such things develop and put forth a policy about how the ietf treats data about members, attendees, network, ... ] And yes we have researchers looking into the traffic, people storing all sorts of data, etc. we do? about our traffic on the ietf meeting network? stuff other than the _ephemeral_ data the noc ops use to manage the network? as far as i know o data collection has been done very rarely. and when it has been, it has been widely announced. o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view o but i am sure there are wifi spies snooping and playing. and i suspect that they will not be very respectful of any policy put in place. given the latter, i focus more on prudent personal net hygene and less on prose. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
Hi Randy, [ fwiw, i am not bothered if some folk well-versed in such things develop and put forth a policy about how the ietf treats data about members, attendees, network, ... ] And yes we have researchers looking into the traffic, people storing all sorts of data, etc. we do? about our traffic on the ietf meeting network? stuff other than the _ephemeral_ data the noc ops use to manage the network? Yes, the IETF meeting network. as far as i know o data collection has been done very rarely. and when it has been, it has been widely announced. Openness and transparency is one of the privacy principles. (but there are others...) o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. I don't know. There is no central place where I could lookup any of this info. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view Maybe boring for you. Some consider it a very large WLAN network, some others test their favorite tunneling technology with it, etc. o but i am sure there are wifi spies snooping and playing. and i suspect that they will not be very respectful of any policy put in place. You have to see all privacy principles in combination in order for them to make sense. given the latter, i focus more on prudent personal net hygene and less on prose. That's fine. Ciao Hannes randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
And yes we have researchers looking into the traffic, people storing all sorts of data, etc. we do? about our traffic on the ietf meeting network? stuff other than the _ephemeral_ data the noc ops use to manage the network? Yes, the IETF meeting network. cites, please. o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. I don't know. There is no central place where I could lookup any of this info. but you suspect the worst? i am on the noc ops team. you can trust my statement or not. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view Maybe boring for you. Some consider it a very large WLAN network, some others test their favorite tunneling technology with it, etc. that is not gathering data on others' use of the network. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
A few more privacy policies for comparison: ISO -- http://www.iso.org/iso/support/privacy_policy.htm IEEE -- http://www.ieee.org/security_privacy.html?WT.mc_id=hpf_priv Note that IEEE uses a layered notice to some extent, which is fairly popular among privacy policy authors these days -- a layered policy shows the essential information on one page or at the top of the page and includes links to other pages or sections with further information. That could certainly be an option for the IETF. IEEE also includes a section on law enforcement requests for data. In my strawman, I was aiming to be as comprehensive as possible on the theory that it would be easier to take things out than to dig them up and add them later. I used a few models (most obviously CDT's policy -- http://cdt.org/content/privacy-policy) and cribbed some language directly from the ISOC policy. Alissa On Jul 9, 2010, at 10:45 AM, Fred Baker wrote: On Jul 8, 2010, at 11:06 PM, Henk Uijterwaal wrote: RIPE is an open group of people interested in IP based networks in Europe and surrounding areas. There is no formal membership, work is done by volunteers, anybody who is interested can join the mailing lists and participate, anybody who pays the meeting fee can attend the meeting and participate there. From an organizational point of view, it is pretty similar to the IETF. This is getting fairly far afield of the topic, but let me explain where I'm coming from. I did a google search for privacy statements, and came to http://labs.ripe.net/node/49 . Poking around, I found http://www.ripe.net/membership/gm/gm-may2010/evoting-announcement.html , which is about RIPE NCC membership, attendees, and voting. I also found another statement that said it was from RIPE (as opposed to the RIPE NCC) and listed members, voting, and attendees, but now I'm not dredging that up. To bring matters back to the topic, the discussion was on Alissa's draft, and I was looking for comparable privacy statements to compare. My question was is this a reasonable statement? Are there things it could have said more simply? Are there things it left out? Are there things it should not have included? ___ 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: Comments on draft-cooper-privacy-policy-01.txt
On 7/9/2010 5:15 AM, Hannes Tschenig wrote: WHAT specifically does Openness and Transparency mean - not in nebulous namby pamby terms but specific sets of use rules and their oversight - what exactly does this mean? as far as i know o data collection has been done very rarely. and when it has been, it has been widely announced. Openness and transparency is one of the privacy principles. (but there are others...) o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. I don't know. There is no central place where I could lookup any of this info. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view Maybe boring for you. Some consider it a very large WLAN network, some others test their favorite tunneling technology with it, etc. o but i am sure there are wifi spies snooping and playing. and i suspect that they will not be very respectful of any policy put in place. You have to see all privacy principles in combination in order for them to make sense. given the latter, i focus more on prudent personal net hygene and less on prose. That's fine. Ciao Hannes randy ___ 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: Comments on draft-cooper-privacy-policy-01.txt
On 7/9/2010 4:32 AM, Hannes Tschofenig wrote: Hi Bob, just a very quick reaction to your mail: ~snip~ I have issues with the Introduction. The first sentence says: In keeping with the goals and objectives of this standards body, the IETF is committed to the highest degree of respect for the privacy of IETF participants and site visitors. This makes it sound like the highest priority of the IETF is Privacy. I don't think this is true as I described above. The vast majority of what the IETF does in Public. There is very little that is Private. The IETF is careful about what needs to be kept private and does not disclose it Everything you have said is true but in this case the specific use of the privacy policy is in this case to provide people who are slammed with SPAM from people illegally harvesting contact information from IETF postings and mailing list activity to create their own personal commercial email lists and NOT to protect their identity or who they represent... You cannot take that away from them no matter what - and since the IETF in its raging toothless manner fails to protect that data itself, it is up to the IETF to enable everyone else to protect themselves from damage which occurs to them by being in the IETF. Also on the other side of the privacy coin, you will find that EVERYONE here has a formal legal right to know who everyone else is representing in the IETF meaning that there is no direct privacy control possible. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)
Cullen, This example is excellent - thank you for providing it. I think it is pretty representative of other examples I have seen and I am in favor of having solutions to use cases such as this - I'm just not seeing why this charter is the appropriate way to do it. Given we are talking about transferring some information between UA in a single providers network, Laura: As I wrote in a previous e-mail, we also have enterprise customers which already bought this feature from us for the PSTN. We don't know how they use it, but we need to give them the same feature for SIP. PS - I doing my best to avoid the debate on if the CSCF are proxies or B2BUA, I view things that need to understand and even change SIP bodies as B2BUA but regardless, I think we can both agree that CSCF can and do look at bodies such as SDP and would work with what I proposed above. Laura: In IMS we have different kinds of CSCFs. In principle, all of them can be either proxy or some kind of B2BUA. In the DT IMS, the CSCF doing SIP-routing and filtering based on user profile, is a proxy. (Other CSCFs, e.g. those at the network border, are B2BUAs, but they can not do the filtering.) Is it so easy to instruct a proxy to inspect the body and eventually throw away a part of it? And should one do that? Thanks Laura 2010/7/7 Cullen Jennings flu...@cisco.com: This example is excellent - thank you for providing it. I think it is pretty representative of other examples I have seen and I am in favor of having solutions to use cases such as this - I'm just not seeing why this charter is the appropriate way to do it. Given we are talking about transferring some information between UA in a single providers network, and this information would likely be stripped by an SBC at the edge of the network, and that different operators may use the same code points for different things, this all seems like something that might just be better carried in one of the existing SIP extensibility mechanisms such as media-type out of the vendor tree. Cullen PS - I doing my best to avoid the debate on if the CSCF are proxies or B2BUA, I view things that need to understand and even change SIP bodies as B2BUA but regardless, I think we can both agree that CSCF can and do look at bodies such as SDP and would work with what I proposed above. On Jul 1, 2010, at 6:53 AM, Laura Liess wrote: In the PSTN, we use the UUI field to transmit information between the Intelligent Network (IN) system and call center agents for the directory enquires service. Everybody in Germany who wants to ask for the phone number of another person dials DT's directory enquires service and is connected to a call center agent who tells him the number he wants to know. Additionaly, only if the caller is a DT customer, the call center agent offers to connect him to this number, so the caller does not need to dial. For everybode else, he does not. So the call center agent needs to get the information whether or not the caller is a DT customer. This is done by routing every directory enquires call to the IN system first. The IN system checks the caller number and inserts the information about whether or not the caller is a DT-customer in the UUI field which is transmited via INAP, ISUP and DSS1 to the call center agent's end device.The call center agent gets a display about this. During the PSTN-migration to SIP, we will have cases where the call center and the IN system are connected to different networks, one to PSTN and the other to SIP. Also, we may have applications as above on pure SIP application servers. Can you shed some light on *how* this is used, given the lack of any standards on the content/formatting of this information? The application is DT-specific and needs a DT specification to be supported by the IN system and the call center, but the container to transport the information must be supported by both ends and by the network nodes. Or is this only used between a caller and a callee that have somehow obtained contextual information that they both support this feature *and* a particular encoding? At least within the DT network, UUI is used between application servers or application servers and special end devices as call centers. As far as I know, UUI is currently not part of the DT normal telephony package. Many years ago, it was, but people misused it. We plan to use the Johnston uui draft for the scenario described above and we see the need for the proposed WG. Thanks a lot Laura Laura 2010/6/30 Paul Kyzivat pkyzi...@cisco.com: James, Can you shed some light on *how* this is used, given the lack of any standards on the content/formatting of this information? Do you use content=isdn-uui and some particular Q.931 protocol discriminator for which there are formatting standards? Or is this only used between a caller and a callee that have somehow obtained contextual
Re: Comments on draft-cooper-privacy-policy-01.txt
Randy, this privacy policy effort is not a means to put someone in the spotlight because a mistake has been made. I think it is good that we do all sorts of experiments with the IETF network and use it for research purposes. Still, if someone wants to do their tests then they should do it in an open and transparent fashion and tell people what they do. The writeup should then contain information like * what data is collected * what is the purpose * how long is it stored * how is responsible * how does the opt-in procedure work It would also be nice to hear the results of the effort afterwards as well. Without listing other persons efforts I would like to mention the location server experiment a few of us did from the GEOPRIV working group. I don't recall anymore how we announced it and what we said in our announcement (it was a few years ago already) but a document like the one written by Alissa would have helped us. Richard Barnes might remember the details. Ciao Hannes Original-Nachricht Datum: Fri, 09 Jul 2010 21:28:43 +0900 Von: Randy Bush ra...@psg.com An: Hannes Tschofenig hannes.tschofe...@gmx.net CC: ietf@ietf.org Betreff: Re: Comments on draft-cooper-privacy-policy-01.txt And yes we have researchers looking into the traffic, people storing all sorts of data, etc. we do? about our traffic on the ietf meeting network? stuff other than the _ephemeral_ data the noc ops use to manage the network? Yes, the IETF meeting network. cites, please. Remember the discussion about the RFID experiment, the location server experiment, o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. I don't know. There is no central place where I could lookup any of this info. but you suspect the worst? i am on the noc ops team. you can trust my statement or not. I don't suspect anything. I believe it is good if people use the network for all sorts of tests, if they tell us what they do. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view Maybe boring for you. Some consider it a very large WLAN network, some others test their favorite tunneling technology with it, etc. that is not gathering data on others' use of the network. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
this privacy policy effort is not a means to put someone in the spotlight because a mistake has been made. what an amazing turn of argument. there are communists in the state department, i have their names on this sheet of paper which i will not reveal. -- joe mcarthy as a researcher, a net op, and one involved in the ietf network, i took it very seriously when you said ietf *network traffic* was measured and stored for research. And yes we have researchers looking into the traffic, people storing all sorts of data, etc. we do? about our traffic on the ietf meeting network? stuff other the _ephemeral_ data the noc ops use to manage the network? Yes, the IETF meeting network. cites, please. Remember the discussion about the RFID experiment, the location server experiment those are not network traffic i am specifically concerned about the allegation that network traffic was captured and stored. either cite or retract. randy, who thinks it is time to get back off this list ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [ippm] Last Call: draft-ietf-ippm-twamp-reflect-octets (TWAMP Reflect Octets and Symmetrical Size Features) to Proposed Standard
Quick comment. In section 4.2.2, in the first sentence, replace Session-Sender by Session-Reflector. The first sentence should read as follows: When Symmetrical Size mode is selected, the Session-Reflector packet formats for unauthenticated and authenticated/encrypted modes are identical to the core TWAMP specification, section 4.2.1 of[RFC5357]. -Steve -Original Message- From: ippm-boun...@ietf.org [mailto:ippm-boun...@ietf.org] On Behalf Of The IESG Sent: June-30-10 1:06 PM To: IETF-Announce Cc: i...@ietf.org Subject: [ippm] Last Call: draft-ietf-ippm-twamp-reflect-octets (TWAMP Reflect Octets and Symmetrical Size Features) to Proposed Standard The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'TWAMP Reflect Octets and Symmetrical Size Features ' draft-ietf-ippm-twamp-reflect-octets-07.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 ietf@ietf.org mailing lists by 2010-07-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-reflect-octets-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17857rfc_flag=0 ___ ippm mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ippm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Privacy Terminology
A lot of people have difficulty connecting the human level privacy requirement with the technology level. While the linkable/unlikable identifiers technology is important, there is more to privacy than merely concealing identities. For example, consider the firestorm that followed Marty Rimm's infamous CMU CyberPorn study. The study concealed the identity of the participants, but there was still a major privacy problem as the participants had expected that the network operator would not reveal details of their lawful activities to Time Magazine. At the information level, privacy creates restrictions that apply to the redistribution of data. In Alice and Bob land we generally consider a binary choice, either Alice will give the information to Bob or she won't. We do not usually consider the question of what Bob might do afterwards because those problems are not solved easily using cryptography. In the privacy case we are considering the explicit agreements and implicit assumptions that Alice has concerning redistribution of the data to Carol, Doug and through to Zachary. And we are not just talking about the information that is passed explicitly, we are also talking about the data that Alice might infer from her interaction with Bob. And because those implicit assumptions are in part culturally determined, it is very hard to find consensus on what they should be. The community view in Cambridge MA is going to be very different from that in San Francisco CA. And those are places that are very close together (no really). The views in Huston TX or London UK are going to be very different again. And we haven't yet left the Anglosphere. When the cookies mechanism was thrown into the HTTP spec by a commercial entity after an exhaustive fifteen minutes of contemplation, the privacy implications of the HTTP protocol were changed immediately and irrevocably and without any notice to the affected users. I don't think it is acceptable for network protocol designers to throw up their hands and say 'this is hard, we will ignore it'. On Fri, Jul 9, 2010 at 8:03 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, I mentioned the position paper for the W3C Workshop on Privacy for Advanced Web APIs already in my last mail. Within the IAB we had planned a series of activities related to privacy and here is another one: Terminology When you look through various IETF documents you will notice that the term privacy is used here and there but often the meaning varies a lot. If you only look at the privacy related articles in newspapers and magazines you will notice the breadth of the topic. Having terminology to work with is quite crucial to avoid talking past each other. Here is an initial submission for privacy terminology: https://wiki.tools.ietf.org/id/draft-hansen-privacy-terminology-00.html Marit and Andreas had worked on this document for about 10 years outside the IETF and it is frequently cited by those working in the privacy area. We thought it would make sense to bring this work to the IETF, to discuss it in a wider audience, and to produce a stable reference. Again, feedback is appreciated. Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
Very good question, Todd. Nowadays everyone claims to be open and transparent. As an example, here is what the Madrid Resolution http://www.gov.im/lib/docs/odps//madridresolutionnov09.pdf has to say about the openness principle: 1. Every responsible person shall have transparent policies with regard to the processing of personal data. 2. The responsible person shall provide to the data subjects, as a minimum, information about the responsible person’s identity, the intended purpose of processing, the recipients to whom their personal data will be disclosed and how data subjects may exercise the rights provided in this Document, as well as any further information necessary to guarantee fair processing of such personal data. 3. When personal data have been collected directly from the data subject, the information must be provided at the time of collection, unless it has already been provided. 4. When personal data have not been collected directly from the data subject, the responsible person must also inform him/her about the source of personal data. This information must be given within a reasonable period of time, but may be replaced by alternative measures if compliance is impossible or would involve a disproportionate effort by the responsible person. 5. Any information to be furnished to the data subject must be provided in an intelligible form, using a clear and plain language, in particular for any processing addressed specifically to minors. 6. Where personal data are collected on line by means of electronic communications networks, the obligations set out in the first and second paragraphs of this section may be satisfied by posting privacy policies that are easy to access and identify and include all the information mentioned above. Ciao Hannes Original-Nachricht Datum: Fri, 09 Jul 2010 07:36:36 -0700 Von: todd glassey tglas...@earthlink.net An: ietf@ietf.org Betreff: Re: Comments on draft-cooper-privacy-policy-01.txt On 7/9/2010 5:15 AM, Hannes Tschenig wrote: WHAT specifically does Openness and Transparency mean - not in nebulous namby pamby terms but specific sets of use rules and their oversight - what exactly does this mean? as far as i know o data collection has been done very rarely. and when it has been, it has been widely announced. Openness and transparency is one of the privacy principles. (but there are others...) o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. I don't know. There is no central place where I could lookup any of this info. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view Maybe boring for you. Some consider it a very large WLAN network, some others test their favorite tunneling technology with it, etc. o but i am sure there are wifi spies snooping and playing. and i suspect that they will not be very respectful of any policy put in place. You have to see all privacy principles in combination in order for them to make sense. given the latter, i focus more on prudent personal net hygene and less on prose. That's fine. Ciao Hannes randy ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
I understand that you don't like process. Who does? The good thing is that there is very little process (or even no process) for you. The additional effort is for those who run the experiment and maybe they come to the conclusion that there is no risk for others. Ciao Hannes Original-Nachricht Datum: Fri, 9 Jul 2010 08:16:36 -0700 Von: Joel Jaeggli joe...@bogus.com An: Hannes Tschofenig hannes.tschofe...@gmx.net CC: ietf@ietf.org ietf@ietf.org Betreff: Re: Comments on draft-cooper-privacy-policy-01.txt With all due respect the geopriv held experiment at ietf71 could have been done anywhere, and had no impact on participants who were not involved in them. I have zero interest in building process that might impede the activity of people conducting protocol experiments that occur effectively in isolation. Joel's iPad On Jul 9, 2010, at 7:39 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Randy, this privacy policy effort is not a means to put someone in the spotlight because a mistake has been made. I think it is good that we do all sorts of experiments with the IETF network and use it for research purposes. Still, if someone wants to do their tests then they should do it in an open and transparent fashion and tell people what they do. The writeup should then contain information like * what data is collected * what is the purpose * how long is it stored * how is responsible * how does the opt-in procedure work It would also be nice to hear the results of the effort afterwards as well. Without listing other persons efforts I would like to mention the location server experiment a few of us did from the GEOPRIV working group. I don't recall anymore how we announced it and what we said in our announcement (it was a few years ago already) but a document like the one written by Alissa would have helped us. Richard Barnes might remember the details. Ciao Hannes Original-Nachricht Datum: Fri, 09 Jul 2010 21:28:43 +0900 Von: Randy Bush ra...@psg.com An: Hannes Tschofenig hannes.tschofe...@gmx.net CC: ietf@ietf.org Betreff: Re: Comments on draft-cooper-privacy-policy-01.txt And yes we have researchers looking into the traffic, people storing all sorts of data, etc. we do? about our traffic on the ietf meeting network? stuff other than the _ephemeral_ data the noc ops use to manage the network? Yes, the IETF meeting network. cites, please. Remember the discussion about the RFID experiment, the location server experiment, o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. I don't know. There is no central place where I could lookup any of this info. but you suspect the worst? i am on the noc ops team. you can trust my statement or not. I don't suspect anything. I believe it is good if people use the network for all sorts of tests, if they tell us what they do. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view Maybe boring for you. Some consider it a very large WLAN network, some others test their favorite tunneling technology with it, etc. that is not gathering data on others' use of the network. randy ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
was Re: Privacy Terminology - this should not be complex...
On 7/9/2010 7:21 AM, Phillip Hallam-Baker wrote: A lot of people have difficulty connecting the human level privacy requirement with the technology level. PH-B, Look, the IETF is a public entity and yet there are formal disclosure requirements for privacy controls. That is a dichotomy which creates both protection responsibilities and use controls. That said here are some thoughts on the specific areas a privacy policy would impact. Some participants cannot... - This is important since there are also privacy constraints that some global IETF members cannot contractually ameliorate or sign-away and as such it means that those privacy controls must be implemented or those parties cannot participate in the IETF. Disclosure is required for any IP protection - Also the scope of privacy means here in a public forum is another one of the key issues, but since it has been noticed the 'concept of transparency' is one of the attributes the IETF is supposed to embrace, and transparency removes privacy...the issue of how much information is private becomes a problem. If transparency != [privacy] and the IETF[transparency] is real transparency and not some term of art whipped up as icing on the cake, this becomes moot. Creating a privacy policy has broad sweeping impact - As to the effect of creating a privacy policy, the physical creation of the privacy policy has far sweeping implications. For instance the IETF's use licenses need to specifically be restricted to conform to this new policy as well so its not just creating a Policy Statement and walking away, many other documents will need to be revised or they will cease to have legal effect in being set aside or modified in their scope and terms based on the newly formed privacy policy. The goals of the privacy policy are simple. To enforce a set of controls which protect individuals personal Intellectual Property (information about us as individuals) while allowing for the collective vetting of the group Intellectual Properties (i.e. work product and technical info or IETF structure/ops info). Email and personal contact data - So that means all identities and points of contact need to be properly disclosed and there is no license to use that data specifically for any other purpose. I brought this up when I suggested formal changes to the unheavelnly twins (BCP78 79) to specifically state that IETF email contact information may not be used for any purpose outside of the operations of the IETF working group some time ago. Maybe now under the banner of eliminating the need for a formal privacy policy, this can be reviewed. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
Randy, we have had at least one researcher sniffing passwords in plenary WiFi traffic and posting them, to embarrass people into using more secure technology. I believe he was an Ops AD at the time :-) Agreed that personal net hygiene is the solution there. On Jul 9, 2010, at 5:04 AM, Randy Bush wrote: [ fwiw, i am not bothered if some folk well-versed in such things develop and put forth a policy about how the ietf treats data about members, attendees, network, ... ] And yes we have researchers looking into the traffic, people storing all sorts of data, etc. we do? about our traffic on the ietf meeting network? stuff other than the _ephemeral_ data the noc ops use to manage the network? as far as i know o data collection has been done very rarely. and when it has been, it has been widely announced. o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view o but i am sure there are wifi spies snooping and playing. and i suspect that they will not be very respectful of any policy put in place. given the latter, i focus more on prudent personal net hygene and less on prose. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf http://www.ipinc.net/IPv4.GIF ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: Nomcom 2010-2011: Final List of Volunteers
-Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of NomCom Chair Sent: Friday, July 09, 2010 10:31 AM To: IETF Announcement list Subject: Nomcom 2010-2011: Final List of Volunteers As specified in my earlier announcements, solicitation for volunteers is now closed. All volunteers have been checked for eligibility, and have been notified. Thanks to everyone that volunteered! Below is the final list of eligible volunteers (100 total), sorted alphabetically by last name. If your name is not on the list and you think it should be or if it is and it shouldn't be, please contact me as soon as possible. As indicated in the published timeline https://datatracker.ietf.org/ann/nomcom/2372/, if there are any names on the list that you do not believe are eligible, please raise your concern by July 13 before 17:00 PDT (24:00 UTC) If there are any changes before July 15th, I'll post an updated list by the 15th. Per the timeline https://datatracker.ietf.org/ann/nomcom/2372/, the seed values will be available on July 15th. I�ll publish the selection results on July 15th. Regards, Thomas Walsh Chair, Nomcom 2010-2011 nomcom-ch...@ietf.org twa...@juniper.net List of 100 volunteers who have been qualified by the secretariat: -- 1. Jaap Akkerhuis, NLnet Labs; 2. Derek Atkins, Computer and Internet Security Consultant; 3. Gabor Bajko, Nokia; 4. Fred Baker, Cisco Systems; 5. Richard Barnes, BBN Technologies; 6. Ray Bellis, Nominet UK; 7. Lou Berger, LabN Consulting, L.L.C.; 8. Marc Blanchet, Viagenie; 9. Rolf J Blom, Ericsson; 10. Matthew Bocci, Alcatel-Lucent; 11. Scott Brim, Cisco; 12. John Jason Brzozowski, Comcast; 13. Ken Carlberg, G11; 14. Gregory Cauchie, France Telecom Orange; 15. H Anthony Chan, Huawei Technologies; 16. Subir Das, Telcordia Technologies Inc; 17. Wojciech Dec, Cisco; 18. Lilla Dovner, Ericsson AB; 19. Keith Drage, Alcatel-Lucent; 20. John Drake, Juniper Networks; 21. Donald E. Eastlake 3rd, Cisco; 22. Byron Ellacott, APNIC; 23. Mehmet Ersue, Nokia Siemens Networks; 24. Luyuan Fang, Cisco Systems, Inc.; 25. Dorothy Gellert, InterDigital Communications; 26. Eric Gray, Ericsson; 27. Chris Griffiths, Comcast; 28. Wassim Haddad, Ericsson; 29. Michael Hamilton, BreakingPoint Systems; 30. Stephen Hanna, Juniper Networks; 31. Tony Hansen, ATT Labs; 32. Susan Hares, Huawei Technologies; 33. Hugo Salgado Hernandez, NIC Chile; 34. Bernie Hoeneisen, Ucom Standards Track Solutions GmbH; 35. Fangwei Hu (Wei Hu), zte corporation; 36. Feng Hu, Huawei Technologies; 37. Fuqing Huang, Huawei Technologies Co., Ltd.; 38. Luigi Iannone, T-Labs; 39. Joel Jaeggli, Nokia; 40. Edward J. (Ed) Jankiewicz, SRI International; 41. Cullen Jennings, Cisco; 42. Ingemar Johansson, Ericsson AB; 43. Krisztian Kiss, Nokia; 44. Miya Kohno, Juniper Networks; 45. Jouni Korhonen, Nokia Siemens Networks; 46. Suresh Krishnan, Ericsson; 47. Dirk Kroeselberg, Nokia Siemens Networks; 48. Yiu L. Lee, Comcast; 49. Matthew Lepinski, BBN Technologies; 50. Hongyu Li, Huawei Technologies Co. Ltd.; 51. Salvatore Loreto, Ericsson; 52. Wenhu Lu, Ericsson; 53. Terry Manderson, ICANN; 54. Scott Mansfield, Ericsson; 55. Enrico Marocco, Telecom Italia; 56. Arifumi Matsumoto, NTT PF Labs; 57. Jan Melen, Ericsson; 58. Telemaco Melia, Alcatel-Lucent; 59. David Meyer, Cisco Systems; 60. George Michaelson, APNIC; 61. Frederico A C Neves, NIC.br; 62. Glenn Parsons, Ericsson; 63. Keyur Patel, Cisco Systems; 64. Basavaraj Patil, Nokia; 65. Charles Perkins, Tellabs; 66. Simon Perreault, Viagnie; 67. Leon Portman, NICE Systems; 68. Pete Resnick, Qualcomm Incorporated; 69. Behcet Sarikaya, Huawei USA; 70. Teemu Savolainen, Nokia; 71. Christian Schmidt, Nokia Siemens Networks; 72. Shida Schubert, NTT; 73. John Scudder, Juniper Networks; 74. Jan Seedorf, NEC Laboratories Europe; 75. Karen Seo, BBN Technologies; 76. David Sinicrope, Ericsson; 77. Haibin Song, Huawei Technologies; 78. Pete St. Pierre, Oracle; 79. Andrew Sullivan, Shinkuro; 80. George Swallow, Cisco Systems; 81. Mark Townsley, Cisco; 82. Brian Trammell, ETH Zurich; 83. Ole Troan, Cisco; 84. Tina TSOU (Ting ZOU), Huawei Technologies Co.,Ltd; 85. Gunter Van de Velde, Cisco Systems; 86. Huub van Helvoort, Huawei Technologies; 87. Stephan Wenger, Vidyo, Inc.; 88. Steven Craig White, BT; 89. Klaas Wierenga, Cisco Systems; 90. Rolf Winter, NEC Labs Europe; 91. Qin Wu, Huawei Technologies; 92. Huaru Yang, Huawei Technologies; 93. Jiankang Yao, CNNIC; 94. Lucy Yong, Huawei Technologies; 95. Kurt Zeilenga, Isode Limited; 96. Zachary Zeltsan, Alcatel-Lucent; 97. Dacheng Zhang, Huawei; 98. Lixia Zhang, UCLA; 99. Yi Zhao, Huawei USA; 100. Ning Zong, Huawei Technologies; ___ IETF-Announce mailing list ietf-annou...@ietf.org
Re: [TLS] Second Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
At 10:21 AM -0700 7/9/10, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Extensions: Extension Definitions ' draft-ietf-tls-rfc4366-bis-09.txt as a Proposed Standard The purpose of this Second IETF Last Call is to confirm some changes made as a result of the first IETF Last Call and subsequent discussions. The main issue was handling of the Server name indications: dealing with multiple names and dealing with session resumption. Also a discussion in the security considerations on why SHA-1 is acceptable for extensions that use it. I support the new wording for both. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
Randy, we have had at least one researcher sniffing passwords in plenary WiFi traffic and posting them, to embarrass people into using more secure technology. I believe he was an Ops AD at the time :-) o but i am sure there are wifi spies snooping and playing. and i suspect that they will not be very respectful of any policy put in place. and if you are remembering that i did so, my admittedly mediocre memory tells me it was not i. though i may have help get stage time for it, not sure. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-kitten-gssapi-naming-exts (GSS-API Naming Extensions) to Proposed Standard
The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Kitten (GSS-API Next Generation) WG (kitten) to consider the following document: - 'GSS-API Naming Extensions ' draft-ietf-kitten-gssapi-naming-exts-08.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 ietf@ietf.org mailing lists by 2010-07-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-08.txt Here are my comments: 1) Section 3 says: An attribute is 'authenticated' iff there is a secure association I suggest expanding iff for clarity. 2) Section 7 defines several new APIs, but I cannot find discussion about who is responsible for de-allocating the output buffers: the caller or the GSS-API implementation. For example, in section 7.1 the 'display_name' parameter is defined as: o display_name STRING First, it should probably be OCTET STRING, not STRING, at least I cannot find any type called only STRING in RFC 2743. Secondly, also compare how RFC 2743 clarifies who is responsible for memory de-allocation like this: o interprocess_token OCTET STRING -- caller must release -- with GSS_Release_buffer() Something similar is needed. 3) The C-binding sections are not complete, they need to describe semantics for the function and its parameters. Compare how RFC 2744 defines each function and discusses each parameter. For the interprocess_token above, there is this text: interprocess_token buffer, opaque, modify token to be transferred to target process. Storage associated with this token must be freed by the application after use with a call to gss_release_buffer(). I expect similar text for each C function and its parameters. 4) The mapping of PKIX subjectAltNames to values is fuzzily described in section 6.2: PKIX certificate subjectAltNames MUST be mapped as *authenticated* GSS-API name attributes. The values SHOULD be the values of the subjectAltName represented as OCTET STRINGs if the type of the subjectAltName supports a unique loss-less representation as string values. Specifically dnsName, ipAddress, uniformResourceLocator and emailAddress MUST be returned using the corresponding string representation of those data types. 6.2.2. Other PKIX Certificate Extensions and Attributes Any X.509 certificate extension not covered above SHOULD be represented as GSS-API name attributes with the OID of the X.509 extension and with OCTET STRING values containing the encoded value of the extension. Is supports a unique loss-less representation intended to _only_ mean dnsName+ipAddress+uniformResourceLocator+emailAddress or are other types also intended to be covered if they, decided by each implementer, can be uniquely and loss-lessly converted? For good interop, I believe the document should clarify for each supported type exactly how translation should work, and not leave this aspect implementation defined. For example, the ipAddress extension holds binary data (of arbitrary length, for IPv4+IPv6), and there are several data formats permitted (127.0.0.1, 127.1, 127::1, etc). It should specify a unique data format. Further, the text above is not clear how the commonly used XMPP subjectAltName extension is translated because that uses an SubjectAltName otherName type. Again, these problems would be solved if the document contains an explicit list of SAN types that are supported and describe exactly how they are converted to string values. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dispatch] VIPR - proposed charter version 3
Richard Shockey wrote: RS You cannot authoritatively determine a binding between a phone number and a consumer (domain) without access to the databases. The point of ViPR is that the authoritative mapping as you've defined it just isn't necessary; a forward routability check is all that is really needed. Indeed, let us look at email for a moment. How does one know that jdro...@jdrosen.net authoritatively maps to me? In reality the only authoritative source for this is the databases at jdrosen.net which contain credentials that are bound to me. However, those are inaccessible to the rest of the world. Instead, one can check if jdro...@jdrosen.net routes to me by sending me an email with some kind of secret, and if I can prove I know that secret, you know that I'm jdro...@jdrosen.net. This forward routability check is the foundation for vast amounts of web security and identity, and that same principle is applied here for phone numbers. Do you argue that we should stop using these forward email routing checks in the web? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology StrategistMobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdro...@skype.net http://www.skype.com jdro...@jdrosen.nethttp://www.jdrosen.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF privacy policy - update
+1 also Monique -Original Message- From: ietf-boun...@ietf.org on behalf of Fred Baker (fred) Sent: Thu 7/8/2010 12:07 PM To: IETF-Discussion list Subject: Re: IETF privacy policy - update +1 for a privacy policy. As to the question of this particular one, I'm going to profess some level of ignorance. I suggested starting from Google, Cisco, and/or ISOC's privacy policies and editing from there, and someone said I should pick a more appropriate starting point. What would be appropriate privacy policies to compare/contrast? Personally, apart from references to ISOC-specific things, I thought ISOC's privacy policy was relatively simple and covered the major points. The draft is more detailed and more complete. The differences may be a matter of taste: look at http://www.isoc.org/help/privacy/ and ask yourself whether the provisions in what do we collect and what do we do with it are reflected in the draft, and I think you might agree that they are, with the draft being more explicit in different areas. But I think that the ISOC rules, when considered in an IETF light, are actually the same. We collect things that are standardly collected, but we don't share them, and we do use them to make our internal processes work better. If there are others to compare/contrast, to see if we have missed a point or are stating for something not usually said, I'd be interested to know. I would agree that this statement should be made by someone in I* leadership, either the IESG, IAOC, or perhaps IAB, and that it belongs on a web page as opposed to being in an RFC. I would suggest that a consensus be called for via a hum over VoIPv6. But the web page should be in flat ASCII with no graphics other than ASCII-art. On Jul 7, 2010, at 11:00 PM, Cullen Jennings wrote: On Jul 5, 2010, at 10:05 AM, Alissa Cooper wrote: A few months ago I drew up a strawman proposal for a public-facing IETF privacy policy (http://www.ietf.org/id/draft-cooper-privacy-policy-00.txt). I've submitted an update based on feedback received: http://www.ietf.org/id/draft-cooper-privacy-policy-01.txt In discussing the policy with the IAOC and others, it seems clear that the RFC model is probably not the best model for maintaining and updating a document like this. It is more likely to fall within the scope of the IAOC and/or the Trust. In order for the IAOC to consider taking this on and devoting resources to figuring out what its format should be, they need to hear from the community that a public-facing privacy policy is something that the community wants. So I have two requests for those with any interest in this: 1) Respond on this list if you support the idea of the IETF having a privacy policy (a simple +1 will do). +1 2) If you have comments and suggestions about the policy itself, send them to this list. I would be very happy if the IETF adopted the privacy policy proposed in your draft. It seems to me the work of writing an acceptable policy is 90% done and the arguments that creating a privacy policy will detract from other work are pretty weak. It's a volunteer organization, people vote with their feet with what they want to work on. Just because Alissa spend time writing a policy document does not mean that time would be directed to other things if we did not want to do a privacy policy document. I don't think that having a privacy policy is going to bring a bunch of new contributors to the IETF, but I can imagine a case where the lack of a privacy policy caused some administrative group to do something really unfortunate which resulted in some good people leaving the IETF. A privacy policy is not something the IETF typically has a lot of people that are really experienced and qualified to draft. But we are very lucky here - we have multiple people that understand IETF culture and values, understand internet privacy policies and laws, and are willing to write a proposal. Unless this proposal is deeply flawed in some way I can't see, why wouldn't we just do it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf http://www.ipinc.net/IPv4.GIF ___ 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
Last Call: draft-ietf-geopriv-arch (An Architecture for Location and Location Privacy in Internet Applications) to BCP
The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'An Architecture for Location and Location Privacy in Internet Applications ' draft-ietf-geopriv-arch-02.txt as a BCP 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 2010-07-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-arch-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18940rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-kitten-gssapi-naming-exts (GSS-API Naming Extensions) to Proposed Standard
The IESG has received a request from the Kitten (GSS-API Next Generation) WG (kitten) to consider the following document: - 'GSS-API Naming Extensions ' draft-ietf-kitten-gssapi-naming-exts-08.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 2010-07-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13136rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-msec-ipsec-group-counter-modes (Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic) to Proposed Standard
The IESG has received a request from the Multicast Security WG (msec) to consider the following document: - 'Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic ' draft-ietf-msec-ipsec-group-counter-modes-05.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 2010-07-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-group-counter-modes-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15718rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pkix-asn1-translation (ASN.1 Translation) to Informational RFC
The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'ASN.1 Translation ' draft-ietf-pkix-asn1-translation-02.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 2010-07-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-asn1-translation-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18604rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pkix-ocspagility (OCSP Algorithm Agility) to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'OCSP Algorithm Agility ' draft-ietf-pkix-ocspagility-08.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 2010-07-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspagility-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18404rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pkix-ta-mgmt-reqs (Trust Anchor Management Requirements) to Informational RFC
The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Trust Anchor Management Requirements ' draft-ietf-pkix-ta-mgmt-reqs-05.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 2010-07-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17349rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Loosely-coupled SIP Devices (LSD)
A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Loosely-coupled SIP Devices (LSD) --- Current Status: Active Working Group Chairs: Simon Pietro Romano sprom...@unina.it Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo gonzalo.camari...@ericsson.com Robert Sparks rjspa...@nostrum.com Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo gonzalo.camari...@ericsson.com Mailing Lists: General Discussion: l...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lsd Archive: http://www.ietf.org/mail-archive/web/lsd/current/maillist.html Description of Working Group: Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams coming from different devices under his or her control so that they are treated by the far end of the session as a single media session. Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the multimedia session. There are a number of existing mechanisms that can be used to coordinate different devices under user's control and to involve them in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] and SIP 3pcc [RFC3725]). However, these mechanisms are intended to be used in tightly coupled scenarios. The use of all those mechanisms requires the presence of a master device. That is, at least one among the different devices under the control of the same user must support the control mechanism and be able to become a controller for the other devices in the call. Moreover, the master device is supposed to remain involved in the user's session for its entire duration given that performing a handover of the master role is typically cumbersome and sometimes impossible. The objective of this working group is to develop a framework for disaggregated media in loosely-coupled scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master. Coordination among devices in this type of scenario is less tight than in the scenarios described above since they do not assume central elements with complete knowledge of the whole media session. While the framework may describe how to use existing mechanisms (e.g., the SIP REFER method) to coordinate devices, the working group will not develop new device coordination mechanisms. The framework may identify the need for new (non-device-coordination) mechanisms to enable the implementation of loosely-coupled scenarios. In case the need for such new mechanisms is identified, the working group will specify them. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key considerations for the exchange of disaggregated media in SIP. The document will include use cases and examples. The document may indentify the need for new mechanisms or extensions to existing mechanisms. 2. Specifications of new mechanisms or extensions to existing mechanisms if the need is identified in the framework. Goals and Milestones: Feb 2011 - Framework document sent to the IESG (Informational) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Second Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Extensions: Extension Definitions ' draft-ietf-tls-rfc4366-bis-09.txt as a Proposed Standard The purpose of this Second IETF Last Call is to confirm some changes made as a result of the first IETF Last Call and subsequent discussions. The main issue was handling of the Server name indications: dealing with multiple names and dealing with session resumption. Also a discussion in the security considerations on why SHA-1 is acceptable for extensions that use it. 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 2010-07-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16186rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2010-2011: Final List of Volunteers
As specified in my earlier announcements, solicitation for volunteers is now closed. All volunteers have been checked for eligibility, and have been notified. Thanks to everyone that volunteered! Below is the final list of eligible volunteers (100 total), sorted alphabetically by last name. If your name is not on the list and you think it should be or if it is and it shouldn't be, please contact me as soon as possible. As indicated in the published timeline https://datatracker.ietf.org/ann/nomcom/2372/, if there are any names on the list that you do not believe are eligible, please raise your concern by July 13 before 17:00 PDT (24:00 UTC) If there are any changes before July 15th, I'll post an updated list by the 15th. Per the timeline https://datatracker.ietf.org/ann/nomcom/2372/, the seed values will be available on July 15th. I�ll publish the selection results on July 15th. Regards, Thomas Walsh Chair, Nomcom 2010-2011 nomcom-ch...@ietf.org twa...@juniper.net List of 100 volunteers who have been qualified by the secretariat: -- 1. Jaap Akkerhuis, NLnet Labs; 2. Derek Atkins, Computer and Internet Security Consultant; 3. Gabor Bajko, Nokia; 4. Fred Baker, Cisco Systems; 5. Richard Barnes, BBN Technologies; 6. Ray Bellis, Nominet UK; 7. Lou Berger, LabN Consulting, L.L.C.; 8. Marc Blanchet, Viagenie; 9. Rolf J Blom, Ericsson; 10. Matthew Bocci, Alcatel-Lucent; 11. Scott Brim, Cisco; 12. John Jason Brzozowski, Comcast; 13. Ken Carlberg, G11; 14. Gregory Cauchie, France Telecom Orange; 15. H Anthony Chan, Huawei Technologies; 16. Subir Das, Telcordia Technologies Inc; 17. Wojciech Dec, Cisco; 18. Lilla Dovner, Ericsson AB; 19. Keith Drage, Alcatel-Lucent; 20. John Drake, Juniper Networks; 21. Donald E. Eastlake 3rd, Cisco; 22. Byron Ellacott, APNIC; 23. Mehmet Ersue, Nokia Siemens Networks; 24. Luyuan Fang, Cisco Systems, Inc.; 25. Dorothy Gellert, InterDigital Communications; 26. Eric Gray, Ericsson; 27. Chris Griffiths, Comcast; 28. Wassim Haddad, Ericsson; 29. Michael Hamilton, BreakingPoint Systems; 30. Stephen Hanna, Juniper Networks; 31. Tony Hansen, ATT Labs; 32. Susan Hares, Huawei Technologies; 33. Hugo Salgado Hernandez, NIC Chile; 34. Bernie Hoeneisen, Ucom Standards Track Solutions GmbH; 35. Fangwei Hu (Wei Hu), zte corporation; 36. Feng Hu, Huawei Technologies; 37. Fuqing Huang, Huawei Technologies Co., Ltd.; 38. Luigi Iannone, T-Labs; 39. Joel Jaeggli, Nokia; 40. Edward J. (Ed) Jankiewicz, SRI International; 41. Cullen Jennings, Cisco; 42. Ingemar Johansson, Ericsson AB; 43. Krisztian Kiss, Nokia; 44. Miya Kohno, Juniper Networks; 45. Jouni Korhonen, Nokia Siemens Networks; 46. Suresh Krishnan, Ericsson; 47. Dirk Kroeselberg, Nokia Siemens Networks; 48. Yiu L. Lee, Comcast; 49. Matthew Lepinski, BBN Technologies; 50. Hongyu Li, Huawei Technologies Co. Ltd.; 51. Salvatore Loreto, Ericsson; 52. Wenhu Lu, Ericsson; 53. Terry Manderson, ICANN; 54. Scott Mansfield, Ericsson; 55. Enrico Marocco, Telecom Italia; 56. Arifumi Matsumoto, NTT PF Labs; 57. Jan Melen, Ericsson; 58. Telemaco Melia, Alcatel-Lucent; 59. David Meyer, Cisco Systems; 60. George Michaelson, APNIC; 61. Frederico A C Neves, NIC.br; 62. Glenn Parsons, Ericsson; 63. Keyur Patel, Cisco Systems; 64. Basavaraj Patil, Nokia; 65. Charles Perkins, Tellabs; 66. Simon Perreault, Viagnie; 67. Leon Portman, NICE Systems; 68. Pete Resnick, Qualcomm Incorporated; 69. Behcet Sarikaya, Huawei USA; 70. Teemu Savolainen, Nokia; 71. Christian Schmidt, Nokia Siemens Networks; 72. Shida Schubert, NTT; 73. John Scudder, Juniper Networks; 74. Jan Seedorf, NEC Laboratories Europe; 75. Karen Seo, BBN Technologies; 76. David Sinicrope, Ericsson; 77. Haibin Song, Huawei Technologies; 78. Pete St. Pierre, Oracle; 79. Andrew Sullivan, Shinkuro; 80. George Swallow, Cisco Systems; 81. Mark Townsley, Cisco; 82. Brian Trammell, ETH Zurich; 83. Ole Troan, Cisco; 84. Tina TSOU (Ting ZOU), Huawei Technologies Co.,Ltd; 85. Gunter Van de Velde, Cisco Systems; 86. Huub van Helvoort, Huawei Technologies; 87. Stephan Wenger, Vidyo, Inc.; 88. Steven Craig White, BT; 89. Klaas Wierenga, Cisco Systems; 90. Rolf Winter, NEC Labs Europe; 91. Qin Wu, Huawei Technologies; 92. Huaru Yang, Huawei Technologies; 93. Jiankang Yao, CNNIC; 94. Lucy Yong, Huawei Technologies; 95. Kurt Zeilenga, Isode Limited; 96. Zachary Zeltsan, Alcatel-Lucent; 97. Dacheng Zhang, Huawei; 98. Lixia Zhang, UCLA; 99. Yi Zhao, Huawei USA; 100. Ning Zong, Huawei Technologies; ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-baker-v6ops-greynet (IPv4 and IPv6 Greynets) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'IPv4 and IPv6 Greynets ' draft-baker-v6ops-greynet-04.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 2010-08-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-baker-v6ops-greynet-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18508rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5920 on Security Framework for MPLS and GMPLS Networks
A new Request for Comments is now available in online RFC libraries. RFC 5920 Title: Security Framework for MPLS and GMPLS Networks Author: L. Fang, Ed. Status: Informational Stream: IETF Date: July 2010 Mailbox:luf...@cisco.com Pages: 66 Characters: 152830 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-mpls-and-gmpls-security-framework-09.txt URL:http://www.rfc-editor.org/rfc/rfc5920.txt This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5921 on A Framework for MPLS in Transport Networks
A new Request for Comments is now available in online RFC libraries. RFC 5921 Title: A Framework for MPLS in Transport Networks Author: M. Bocci, Ed., S. Bryant, Ed., D. Frost, Ed., L. Levrau, L. Berger Status: Informational Stream: IETF Date: July 2010 Mailbox:matthew.bo...@alcatel-lucent.com, stbry...@cisco.com, danfr...@cisco.com, lieven.lev...@alcatel-lucent.com, lber...@labn.net Pages: 56 Characters: 129318 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-tp-framework-12.txt URL:http://www.rfc-editor.org/rfc/rfc5921.txt This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5933 on Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
A new Request for Comments is now available in online RFC libraries. RFC 5933 Title: Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Author: V. Dolmatov, Ed., A. Chuprina, I. Ustinov Status: Standards Track Stream: IETF Date: July 2010 Mailbox:d...@cryptocom.ru, r...@cryptocom.ru, i...@cryptocom.ru Pages: 9 Characters: 17657 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dnsext-dnssec-gost-07.txt URL:http://www.rfc-editor.org/rfc/rfc5933.txt This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). [STANDARDS TRACK] This document is a product of the DNS Extensions 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 Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
