Re: Faraday cages...
My wallet supposedly has a RFID-blocking layer, but I've not actually tested it. I think the only RFID-capable thing in my wallet is my US passport. I used my cell phone in Berlin extensively, both roaming and on wifi, obviously, so both radios were active for most of the time I was there. Clearly, I'm not as para^G^G^G^Gconcerned about being tracked or hacked as some others. Chris. On Wed, Aug 7, 2013 at 11:16 AM, Ted Lemon ted.le...@nominum.com wrote: Dare I ask how many IETFers also kept their cell phones in faraday cages for the duration of the conference? -- Chris Elliott chell...@pobox.com
Re: IETF and APIs
On Mar 29, 2011, at 1:28 PM, Eric Burger eburge...@standardstrack.com wrote: Would we not be better off just asking (mandating?) at least one open source implementation? That effort would produce a de facto API. To co-opt wording from another thread, I think you are conflating an (even de facto) API with an application. I've seen many applications that implement protocols without clearly delineating an interface to the protocol as anything approaching an API. Even if there is a de facto API, it is often unusable unless it was designed as an API fr the ground up and didn't simply grow out of the need to abstract the protocol from the application during development. Chris. On Mar 29, 2011, at 11:17 AM, Sam Hartman wrote: Dave == Dave CROCKER d...@dcrocker.net writes: Dave On 3/29/2011 10:13 AM, Sam Hartman wrote: At the mic at the technical plenary last night, I made a comment that I strongly supported the IETF doing API work. I've realized that people may have assumed I meant that it would be appropriate for the IETF to specify an API and not a protocol for some given task. That's not what I meant, so I am writing to clarify. I think that multiple levels of interoperability will be required for building blocks used in platforms including the web platform. Dave Multiple levels of interoperability sounds interesting, and Dave very possibly quite important. One level is the traditional protocol interoperability we normally discuss. Another level shows up when you want to write a cross-platform application. It's not good enough if Windows has some API. I want to have confidence that functionality is available on Windows, OSX, Linux and some of the mobile platforms before I depend on that functionality in a cross-platform API. Within the web platform, I want to make sure functionality is available on multiple browsers before I depend on it in my cross-browser application. we're the IETF. We should definitely specify protocols for the building blocks we create. However, one problem that hurts interoperability is when platforms provide different APIs or abstract interfaces to applications. Dave ... I think that we should move more into that business. I see no problem with actually specifying a language-specific API when the WG involved has the skills to do a good job. Dave Wow. What is the list of languages we should work on? C, Dave C++, Javascript, Java, Python, ...? Any of the above when it makes sense for a WG to do the work. I'd expect that typically you'd only specify one or two language bindings for a given interface. You should have a need to do the work, have the necessary skills to have probable success, have the necessary skills to get review and have people volunteer to do the work. Dave Which is not to deny the problem you cite: APIs differ and Dave this hurts interoperability. Dave One approach to solving it is, indeed, to specify /all/ of the Dave APIs that map to the protocol. Dave Another is to do more and better interoperability testing and Dave let the API developers see their deficiencies and fix them. Dave The benefit of this is that it moves the problem to the folks Dave with the knowledge and incentives to work on it and it takes Dave this very expensive specification task out of the IETF's Dave critical path. My experience is that protocol interoperability testing does not actually lead to cross-platform interoperability. This is especially true for building blocks intended to be used by components that are developed later. The issue is that the people doing interoperability testing at the protocol layer don't tend to be testing for whether things work the same way between platforms. It is when you try and build something on top of a building block that you notice the problem. You tend to notice at one of two layers. The first is if you standardize the higher level item and have participants familiar with multiple platforms involved in the standardization. You can then discover that you don't have sufficient overlapping functionality on platforms to do what you want. Another case where you discover the problem is when you implement and people discover that they cannot do so. Factors that contribute to cross-platform interoperability issues include the following. Often, the people designing and implementing the building block are not the same as the people using the building block. Often, there is separation in time between building block design and building block usage. Often, various factors complicate changing the platform to expose new functionality. In conclusion, in cases where these types of issues are likely to be important, I believe we should do work. Work can include work on abstract interfaces, which will be easier to justify. Work can include concrete APIs which will sometimes be appropriate. I would prefer
Re: XKCD - Nanobots
Bob, et al.: I took the liberty of informing Randall that he hit the IETF list on his forum here: http://forums.xkcd.com/viewtopic.php?f=7t=68893 May take a bit for my post to get approved. And, yes, I did point out that you commented...and were involved with the development of IPv6... ;-) Enjoy, and see you all in Prague! Chris. -- Chris Elliott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XKCD - Nanobots
And I'll point out that this is not the first xkcd cartoon to be referenced by IETF'ers: http://www.ipv6now.com.au/news/TheStandardAug09.pdf The referenced comic is # 195, Map of the Internet, http://www.xkcd.com/195/ And, as always with xkcd comics, check out the tool tip! Enjoy again! Chris. On Mon, Feb 28, 2011 at 5:39 AM, Chris Elliott chell...@pobox.com wrote: Bob, et al.: I took the liberty of informing Randall that he hit the IETF list on his forum here: http://forums.xkcd.com/viewtopic.php?f=7t=68893 May take a bit for my post to get approved. And, yes, I did point out that you commented...and were involved with the development of IPv6... ;-) Enjoy, and see you all in Prague! Chris. -- Chris Elliott -- Chris Elliott chell...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WiFI and authentication
Lawrence, The authentication on wireless in Maastricht was in preparation for Beijing, where we had an agreement to ensure the wireless users were IETF attendees. I know of no reason to continue the authentication and I know of no intentions of doing so for any currently scheduled meeting. I think we would only have this as a requirement for the network if we go back to China proper (i.e. not Taiwan or Hong Kong) again. Chris. -- Chris Elliott On Dec 29, 2010, at 12:22 PM, Lawrence Conroy lcon...@insensate.co.uk wrote: Hi Folks, whilst everyone is on the topic of WiFi ... Now that the meeting in the PRC is over, is there any intention to continue the WiFi authentication shenanigans? [802.1X stuff, entering the magic number on your badge, ...] That seemed to be another added complexity @ Maastricht, so I'd prefer this to disappear. If this business IS to be continued, why? all the best, Lawrence ___ 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: BCP request: WiFi at High-Tech Meetings
On Dec 29, 2010, at 8:38 AM, Joel Jaeggli joe...@bogus.com wrote: On 12/29/10 8:03 AM, Henning Schulzrinne wrote: I'm curious what the largest *successful* deployment has been (measured in number of participants in a single room/hall/stadium/...) that anybody has seen, within the IETF or beyond. The NYC article hints at the fact that the limit may be hotel fiber, rather than wireless, in some cases. We seem to have more experience with dimensioning those than other organizations. Our network requirements doc at http://iaoc.ietf.org/network_requirements.html is somewhat relevant. hotel facilities range from acceptable to godawful... The IETF has the luxury of getting donations of high speed connectivity to many of our meetings. The biggest problem by far is cochannel interference, and the best way to solve that is more channels. The ability to use 802.11a's 11 non-overlapping bands is the move effective method by far. It's doesn't work if you have to serve 8000 iphones but in a environment full of business class laptops, more that half your customers will move over there by default. I strongly agree here. Encourage .11a (5ghz) usage, disable .11n for the .11b/g 2.4ghz spectrum. We also have the luxury of a large number of repeat attendees, and many of you have learned the benefits of using .11a and will go out of your way to use it. We facilitate that through advertising .11a-only SSID's. So, yes, some of what we've learned would apply to other events, but some is very tailored to the IETF's needs. Chris. joel On Dec 29, 2010, at 10:57 AM, Ole Jacobsen wrote: Dave, I think you will find that our NOC people have a great deal of experience and perhaps even a list of do's and don'ts for this type of design. In the end, this technology will not scale without bonds if we're talking about n-thousand people sitting in a plenary hall, but there are obviously a lot that can be done with a distribution of multiple lower-powered (configured as such) units that don't use overlapping channels, use of various 802.11 flavors (a, n, etc) and more SSIDs, all in the name of load sharing. While there may not be a document, and I agree that it would be useful to have one, there is certainly a collective body of knowledge on this topic (including a never again use base stations from ..). 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 On Wed, 29 Dec 2010, Dave CROCKER wrote: Time for a BCP? http://www.nytimes.com/2010/12/29/technology/29wifi.html?_r=1nl=todaysheadlinesemc=tha25 The problem is that Wi-Fi was never intended for large halls and thousands of people, many of them bristling with an arsenal of laptops, I don't recall seeing a document on this and the IETF track record has been quite good. We should share the joy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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 ___ 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: Admission Control to the IETF 78 and IETF 79 Networks
Phillip, In your earlier email, you state: If the designers had actual brains instead of bits of liver strapped round their waist by dogbert then all that would be necessary to securely authenticate to the network is to give either the MAC address of the computer or the fingerprint of the cert. Note that you say either. Now you state: Of course the MAC address is trivially forged. That is the function of the certificate. Maybe you should check your waist. Chris. -- Chris Elliott chell...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker hal...@gmail.comwrote: No, if you read my book you would see the scheme I am proposing. I hope your book is rather less opaque than your attempts to explain your technique here. The problem with current MAC addresses is that they are not trustworthy. That is accepted. If MAC addresses were not trivially forged then the existing WiFi scheme would work fine. What I am saying is that if people got really serious about usability and in particular the WiFi design had been controlled by a Steve Jobs style person who demanded an absolute commitment to a first class usability approach, then we could have a scheme that did not require end-user configuration. Instead every device would have been issued with a device cert to bind the MAC address to a public key during manufacture. This is already a requirement for cable modems. The cost is of the order of cents per device if the certs are installed during manufacture. Maintenance costs get much higher as soon as the device has left the factory. The function of the certificate is to stop the MAC address being trivially forged. OK yes, if you design the protocols wrong then you can end up with Cisco being able to intercept on the wire traffic. But if you do the job right you can prevent interception even if the manufacturer defects. I thought we were talking about how to do this for the meeting in Maastricht and then in Beijing. I agree that manufacturers could make this easier for all of us. But some of us live in the real world and must make things work today. I'd be glad to listen to an explanation of how to make this work with the current devices that IETF attendees will be bringing to Maastricht and Beijing. Chris. And as for my waist - yes there does seem to be rather more of it than there should be, but I don't think that is Dogbert's fault. I blame the cookies at IETF break time. On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott chell...@pobox.com wrote: Phillip, In your earlier email, you state: If the designers had actual brains instead of bits of liver strapped round their waist by dogbert then all that would be necessary to securely authenticate to the network is to give either the MAC address of the computer or the fingerprint of the cert. Note that you say either. Now you state: Of course the MAC address is trivially forged. That is the function of the certificate. Maybe you should check your waist. Chris. -- Chris Elliott chell...@pobox.com -- Website: http://hallambaker.com/ -- Chris Elliott chell...@pobox.com CCIE # 2013 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
Phillip, I read all of all your emails on this thread before I replied the first time, just not your book. We will be and we have been eat[ing] the WiFi authentication dog-food at IETF meetings. And it's gotten easier each time. You do realize, don't you, that we are offering WPA/WPA2 with enterprise authentication and encryption as our recommended way of getting onto the network, right? We are only offering a web portal so that folks that can't do WPA* can authenticate. And we've been offering WPA* enterprise on most IETF networks for many years. The difference this time is we are going to unique user credentials. I anticipate the time it will take for most attendees to authenticate will be the time it takes to type in a username and password--far under a half an hour, unless the attendee is Stephen Hawking, in which case I will personally help the attendee authenticate! There will be those with problems. That's why there's a help desk. Chris. P.S. bring a copy of your book to Maastricht and I'll bring a copy of mine and we'll do a prisoner exchange. :-) -- Chris Elliott CCIE # 2013 On Jul 12, 2010, at 2:35 PM, Phillip Hallam-Baker hal...@gmail.com wrote: Well maybe if you read the full thread rather than just cherry picking parts of it you would have understood the point better. My original argument was that I think the IETF should eat the WiFi authentication dog-food here because the current product tastes like poo and the only way things are going to get any better is if a bunch of network engineers start to see that there is a real problem. I have also proposed a scheme that would be applicable for use at the IETF. Basically the shortest distance from where we are to where we want to be is to use self signed certs and use the fingerprint of the cert as a unique device ID. But that is only addressing the specifics of how to make the scheme work at IETF, which is really not very interesting in the grand scheme of things. What is more interesting would be a scheme that can be relied on to work anywhere without half an hour of fiddling and jiggering the configuration - as will be the Maastricht/Beijing experience. The first year they started doing this at RSA the help desk had a pretty long queue and much time was spend debugging crappy code. The basic experience being that Macs work fine, Windows works fine with native drivers. But corporate configuration laptops with device drivers written by the WiFi card provider and/or VPN products were massively flaky.. On Mon, Jul 12, 2010 at 1:53 PM, Chris Elliott chell...@pobox.com wrote: On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker hal...@gmail.com wrote: No, if you read my book you would see the scheme I am proposing. I hope your book is rather less opaque than your attempts to explain your technique here. The problem with current MAC addresses is that they are not trustworthy. That is accepted. If MAC addresses were not trivially forged then the existing WiFi scheme would work fine. What I am saying is that if people got really serious about usability and in particular the WiFi design had been controlled by a Steve Jobs style person who demanded an absolute commitment to a first class usability approach, then we could have a scheme that did not require end-user configuration. Instead every device would have been issued with a device cert to bind the MAC address to a public key during manufacture. This is already a requirement for cable modems. The cost is of the order of cents per device if the certs are installed during manufacture. Maintenance costs get much higher as soon as the device has left the factory. The function of the certificate is to stop the MAC address being trivially forged. OK yes, if you design the protocols wrong then you can end up with Cisco being able to intercept on the wire traffic. But if you do the job right you can prevent interception even if the manufacturer defects. I thought we were talking about how to do this for the meeting in Maastricht and then in Beijing. I agree that manufacturers could make this easier for all of us. But some of us live in the real world and must make things work today. I'd be glad to listen to an explanation of how to make this work with the current devices that IETF attendees will be bringing to Maastricht and Beijing. Chris. And as for my waist - yes there does seem to be rather more of it than there should be, but I don't think that is Dogbert's fault. I blame the cookies at IETF break time. On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott chell...@pobox.com wrote: Phillip, In your earlier email, you state: If the designers had actual brains instead of bits of liver strapped round their waist by dogbert then all that would be necessary to securely authenticate to the network is to give either the MAC address of the computer or the fingerprint of the cert. Note
Back to authentication on the IETF network (was: Re: IETF 78: getting to/from/around Maastricht)
We will not be doing 802.1X authentication on any wired ports. Remember, we really want an open network, while giving people a way of encrypting their wireless traffic. This time, in preparation for Beijing, we have the requirement to authenticate that people using the wireless network are attending the IETF meeting. I will suggest that in Beijing we may need to physically authenticate people coming into the terminal room, but I will leave the decision on whether and how to do that up to the host in Beijing. Chris. On Mon, Jul 12, 2010 at 3:22 PM, Iljitsch van Beijnum iljit...@muada.comwrote: Sorry about my previous message, this was a private message that I accidentally sent to the list. The one I really had in mind: On 12 jul 2010, at 19:53, Chris Elliott wrote: I thought we were talking about how to do this for the meeting in Maastricht and then in Beijing. I agree that manufacturers could make this easier for all of us. I have no idea where or why this discussion went off the rails (must be the heat, note that Maastricht is in the part of the Netherlands that gets the warmest in summer) but: WPA works just fine on anything that rolled out of the factory in the last half decade. It's also not particularly hard to use: select network, type user name, type password, click connect or words to the same effect. There is no step 5. I would even argue that restricting everything to WPA2 and 802.11g or better would be entirely reasonable by now. BTW: do we get 802.1x on the wired ports in the terminal room? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Chris Elliott chell...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Back to authentication on the IETF network (was: Re: IETF 78: getting to/from/around Maastricht)
On Jul 12, 2010, at 3:54 PM, Ted Hardie ted.i...@gmail.com wrote: On Mon, Jul 12, 2010 at 12:41 PM, Chris Elliott chell...@pobox.com wrote: I will suggest that in Beijing we may need to physically authenticate people coming into the terminal room, but I will leave the decision on whether and how to do that up to the host in Beijing. Chris. What does physically authenticate people mean here? Show that they have a badge (common and meets the stated requirement of keep the IETF network for IETF attendees)? Or write down the name? Or write down the name and the network port for the cable they pick up? The differences here are not subtle, and I don't think this question really does belong with the hosts in Beijing. They can present requirements to the IETF, but it is up to us to decide how to meet them. If their choice in meeting the requirement keep the IETF network for IETF attendees turns into Track the network usage on a per attendee basis, the attendees really need to know whether that is because that was the real requirement all along or because the IETF management failed to provide a realistic alternative that met the stated goal. Our requirement in Beijing is to meet the government restriction that only attendees of the meeting can access the Internet through our external link. There are no requirements for, and we will certainly not be doing, any monitoring of users. Period. I do not know the layout of the Beijing IETF meeting space. Therefore, I do not know the best approach to securing wired connections in the terminal room and elsewhere. I am suggesting, to be more explicit, that a guard at the door of the terminal room checking that everyone simply has an IETF badge, as we have done in many previous meetings, may be sufficient for Beijing as well, and the easiest solution for all. And we are working hand-in-hand with the Beijing folks first in Maastricht and then Beijing to refine the requirements and the implementation. Four or five of the folks that will be the core of the NOC team in Beijing are members of the NOC team in Maastricht and will be working with us throughout the meeting. Some of them will be staffing the help desk alongside the RIPE folks, so come by and introduce yourselves. Our roles will reverse in Beijing as they will be responsible for the network and we will be there to help. We are well aware of the concerns of IETF attendees around privacy. We share these concerns. Chris. best regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
Yes. Expect them to work and bring cash! That said, some of us with American cards will be arriving the Tuesday before. I'll post the results of our travels and trials . Chris. -- Chris Elliott On Apr 2, 2010, at 4:56 PM, Ralph Droms rdroms.i...@gmail.com wrote: So, with all this discussion, I'm still not clear what to expect. When I walk up to a train ticket kiosk in Schiphol, should I expect to be able to use my US-issued, non-chip credit card (AMEX, VISA - I don't care as long as *one* of them works), or should I have a fistful of Euros handy? - Ralph ___ 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: Advance travel info for IETF-78 Maastricht
Richard, The site for the IETF in Dublin was easily an order of magnitude farther from the city center than the MECC. Google Maps lists several restaurants in the 2-3km range walking. That's doable even by an overweight out-of-shape American like me with the normal 1.5 hours for lunch. Would do me good to spend more time walking than eating. We could even advertise the meeting as a easy to moderate workout week! I like the idea of rental bikes, but I suspect they may sell out faster than rooms in the attached hotel... Enjoy! Chris. -- Chris Elliott On Mar 28, 2010, at 9:55 PM, Richard Barnes rbar...@bbn.com wrote: [Added IAOC] Iljitsch: Thanks very much for this information. I was not aware of this: The MECC conference center is 2 - 3 kilometers from the city center, where the restaurants are. IAOC: I had been getting used to the idea of Maastricht, with it being historic, nice city center and all. Iljitsch's observation makes me wonder if we learned nothing from Dublin, and are now choosing IETF venues from here: http://en.wikipedia.org/wiki/Extreme_points_of_the_World#Remoteness --Richard P.S. WTFIAOC is worth 65 points in Scrabble. 69 points in the Dutch edition! Ground transport: Maastricht is located in the far southeast of the Netherlands, 215 km (by road) from Amsterdam. The city is located on the Belgian border and is also very close to Germany. There are some smaller airports closer to Maastricht than the ones mentioned below, but those don't serve many destinations and don't connect to the rail network so more hassle and as much or more time to reach Maastricht despite the shorter distance. Only consider these smaller airports if you know what you're doing. You can of course rent a car at one of the airports and drive to Maastricht, and even commute between the MECC and your hotel by car if the hotel is located outside the inner city, but you'll probably need to get into the city for dinner anyway and being a few thousand years old, Maastricht's city center isn't really built for cars. The most convenient airport to use would be Schiphol (Amsterdam) airport. From there, it takes about 2 hours, 35 minutes with one change to get to Maastricht by train with a connection every 30 minutes. A second class one way ticket is 27.50 euros. The last train from Schiphol to Maastricht is at 22:16. The first train to Schiphol arrives at nine. A good alternative is Brussels, from where Maastricht is about two hours with one or two changes and one connection per hour with regular national and international trains. The last connection to Maastricht is at around 21:39. The first train to Brussels airport arrives at nine on weekdays, ten on weekends. There are also a few high speed train connections which save you 30 minutes. If you're arriving in Europe through Frankfurt or Paris, it may not make too much sense to first connect to Amsterdam or Brussels and then sit in a train for a few more hours. You may as well take the train directly from these airports to Maastricht. However, consider that missing train/plane connections is your problem, while plane/ plane connections are the airline's problem. (Financially, at least.) From Frankfurt, there is one connection per hour (weekdays) or one every two hours (weekends) that takes 4 hours, 46 minutes with regular national and international trains. The last connection to Maastricht without high speed trains leaves at around 18:22. The first connection to FRA without high speed trains arrives at 13:36. From Frankfurt it is (of course) faster to take a high speed train, and from Paris it's the only option. The downside of high speed trains is that you can't just hop on like on a regular train, you need to book or reserve a seat on a specific train. Also, they run less often so if you miss one, you're in big trouble. Also check prices before you book (usually available 90 days before the travel date), international trains in general and especially high speed trains can be quite expensive. From Frankfurt, there is an ICE connection several times a day that takes between 3 hours and 3 hours 41 minutes with 2 or 3 changes. The last connection to Maastricht is at 21:09. The first connection to FRA arrives at 10:16, 11:51 on sundays. From Paris, there is a thalys connection every two hours or so in the weekend and a bit more often during weekdays. The journey takes between 3 hours, 15 minutes and 4 hours, 10 minutes, with one or two changes. The last connection to Maastricht is at 20:04 on weekdays and 18:49 on weekends. On weekdays, the first train to CDG arrives at 10:44, on the weekends 11:36. You can also get from Heathrow to Maastricht in 5 to 6 hours with 2 or 3 changes, but as the last connection from Heathrow is around five and from Maastricht the first one arrives at around noon (two hours later
Re: Regd ospfASBdrRtrStatus
Raj kiran, The answer to this question will depend on the specific implementation of the MIB module. SNMP allows vendors to detail specifics of their implementations in capability files. However, in my experience, few vendors have published many capability files and even for those that have, the coverage is limited. It turns out that Cisco has published a capability file for the OSPF-MIB detailing their support for this object. This capability file may be found here: ftp://ftp.cisco.com/pub/mibs/v2/CISCO-OSPF-CAPABILITY.my This file only documents the state of the implementation of this MIB module for Cisco IOS versions: PRODUCT-RELEASE Cisco IOS 12.0(26)S, IOS 12.2(31)SB2, IOS 12.2(18)SXF2, IOS 12.2(18)SXE, IOS 12.3(4)T And the information for this object states: VARIATION ospfASBdrRtrStatus ACCESS read-only DESCRIPTION Unable to create or modify I am reasonably certain that the implementation details for this object for later IOS versions is unchanged. So, your question does not apply to equipment running Cisco IOS as you cannot set this object on such devices. Chris. On Fri, Mar 19, 2010 at 5:10 AM, Raj kiran nrajki...@gmail.com wrote: Hi, The description of ospfASBdrRtrStatus object in OSPF-MIB (RFC 1850) says that it is a flag to note whether this router is configured as an ASBR. My question is whether this object can be set irrespective of any other configuration or any pre-requisites have to be satisfied. Thanks in advance. Raj kiran ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Chris Elliott chell...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: why can't IETF emulate IEEE on this point?
You mean like: https://datatracker.ietf.org/ipr/about/ ? Chris. On Tue, 25 Sep 2007, Paul Vixie wrote: in http://www.theregister.co.uk/2007/09/21/802_11n_patent_threat/, we see: Letters of Assurance are requested from all parties holding patents which may be applicable to any IEEE standard. Basically they state that the patent owner won't sue anyone for implementing the standard. ... i was thinking, what a great policy. why doesn't IETF have one like it? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA | | 919-392-2146 .:|:|:. [EMAIL PROTECTED]c i s c o S y s t e m s ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: why can't IETF emulate IEEE on this point?
On Tue, 25 Sep 2007, Paul Vixie wrote: You mean like: https://datatracker.ietf.org/ipr/about/ no, i was thinking of the promise not to sue, rather than the promise to disclose the possibility of suing. You mean like: Cisco is the owner of US published patent applications 20050154872 and 20050154873 and one or more pending unpublished patent applications relating to the subject matter of Transport Layer Security (TLS) Session Resumption without Server Side State draft-salowey-tls-rfc4507bis-01.txt. If technology in this document is included in a standard adopted by IETF and any claims of any Cisco patents are necessary for practicing the standard, any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard. The reasonable non-discriminatory terms are: If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against any products of Cisco or any products of any of Cisco's affiliates either alone or in combination with other products; and Cisco retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. Royalty-bearing licenses will be available to anyone who prefers that option. - This is from one of Cisco's IPR disclosures...the first I found. Seems pretty clear (for legal-ese) to me. Chris. -- Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA | | 919-392-2146 .:|:|:. [EMAIL PROTECTED]c i s c o S y s t e m s ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Identifying meeting attendees
While we're tagging attendees, let's get robots to follow them around and give everyone connectivity wherever they are--and track them: http://www.computerworld.com/action/article.do?command=viewArticleBasictaxonomyName=wireless_trends_and_technologiesarticleId=9014819taxonomyId=78 Maybe the robots could visually track attendees as well and remind them that they left their badge in their room/car/plane/etc. :-) Enjoy! Chris. -- Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA | | 919-392-2146 .:|:|:. [EMAIL PROTECTED]c i s c o S y s t e m s ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Survey Results
On Mon, 23 Jan 2006, Ken Raeburn wrote: On Jan 23, 2006, at 21:57, JORDI PALET MARTINEZ wrote: In my own case, having a Mac is not easy to get built-in 802.11a. I can of course buy an external card, Are there cards with Mac OS X drivers nowadays? If I knew where to get one, I'd consider it, given the condition of the 802.11b/g network too much of the time. (Or are you running Linux kernels on your hardware?) Yes, several. Specifically, I gave 17 of the old Cisco .11a-only cards away in Vancouver, mostly to Mac folks. Chris. Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA | | 919-392-2146 .:|:|:. [EMAIL PROTECTED]c i s c o S y s t e m s ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [58crew] RE: IETF58 - Network Status
On Thu, 13 Nov 2003, Randy Bush wrote: basic lessons previously learned were not put to use here, e.g., lowering the radios so wetware limits range and reduces xmtrs bandwidth fight. Right. Like this really works. This just ensures that the folks in the middle of the room will get really bad performance. Been there. Chris. randy ___ 56crew mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/56crew Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA | | 919-392-2146 .:|:|:. [EMAIL PROTECTED]c i s c o S y s t e m s
