Re: About cookies and refreshments cost and abuse
Hi Cyrus, As I tried to explain in my previous email, in a recent event, they didn't needed extra hotel staff, because they put a box where the meeting participant drop his ticket in the row where the food is picked up. Then is quite evident if you abuse, even to the rest of the participants because you're picking up food several times and only had a ticket the first one. In any case, its clear that if there is extra cost, it may not make sense the balance between that extra cost and the food not-abused. However, what it is important here for all the participants is that we realize as soon as possible that, since already at least a couple of years ago, IETF is in need to try to reduce meetings cost and manage them in a long-term planning which helps to reduce that cost. All what each participant can do to help here, is very important. I know that the new management is taking care of this and paying attention to all our comments and inputs, and I'm sure they are already doing a good job. All of us need to understand their decisions and make sure to help them on whatever we can. Regards, Jordi De: Cyrus Daboo [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Fri, 24 Mar 2006 12:32:09 -0500 Para: ietf@ietf.org ietf@ietf.org CC: [EMAIL PROTECTED] Asunto: Re: About cookies and refreshments cost and abuse Hi JORDI, --On March 23, 2006 5:32:29 PM -0600 JORDI PALET MARTINEZ [EMAIL PROTECTED] wrote: So my suggestion to be reasonable and fair to all, will be to provide together with our registration pack, a given number of refreshment tickets, enough to cover the average needs. The problem with tickets is who do you get to collect them? Presumably this would have to be hotel staff - at which point the costs will go up as they would likely need to employ more staff to collect tickets in addition to bringing out new trays etc. That would probably lead to having to have fewer refreshment stations and result in longer queues to get those refreshments. Something that might help with at least the estimation process that is currently done, would be to include a breakfast/break sign-up option on the online registration form. The form already asks about attendance at the Sunday reception, so why not extend that to the refreshment breaks? Obviously not everyone registers before hand (what is the percentage BTW?) but this still might be better... -- Cyrus Daboo ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
Hi Bill, I'm not really sure that was the reason (or not the only one), because it seems was sorted out after the first day, then the problem reappeared in the same or different meeting rooms. Of course, it could be possible that it was depending on what AP your are being associated. My experience organizing 800 people events and using existing infrastructure has been always that if I'm not able to take control of all the equipment (making a backup of the existing configuration, using my own one, and then restoring the configuration when the event is finished so the original owners don't complain), then I only use cabling, and pure L2 devices (if required). At this way, I never got this problem. In one occasion, last summer, the APs where hanging on a kind of smart AP switch, which didn't talked IPv6 at all and I was not allowed to replace or configure in a different way. The solution was easy. We used on additional L2 switch between the APs and the smart AP-switch to inject IPv6 (only). So the IPv4 was still coming from the existing infrastructure, but IPv6 was also provided under our own control. Regards, Jordi De: Bill Fenner [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sat, 25 Mar 2006 15:44:56 -0800 Para: [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: An absolutely fantastic wireless IETF I also noticed that IPv6 disappeared from the network and reported it to the NOC. I think they figured out the problem at least in one of the APs or whatever it was. I've requested to know the reason but got no information at the time being. Jordi, At the heart of this problem was that we were using the hotel's existing switch infrastructure, since they already had ports all over the place, and it also allowed us to use their existing APs as well as our own. Unbeknownst to us, their switches were configured with the security options, 'switchport block unicast' and 'switchport block multicast'. The first meant that if the switch forgot a MAC address before the end device's ARP table did (e.g., because there are lots of MAC addresses flying around the network at a big meeting), that connectivity between the two systems would be blackholed. This caused a great deal of trouble with our monitoring station and also with the printers. The second meant that the IPv6 ND / RA packets, sent to arbitrary multicast addresses, were not forwarded since the switch didn't think that the multicast should go to these ports. After asking the hotel's provider to remove these restrictions, IPv6 worked again. There were still some isolated incidents which we were unable to completely debug but could be explained by some lingering 'switchport block' commands. This was the first time (to my knowledge) that we used a venue's existing infrastructure so heavily. It certainly taught us a few things. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
On Sat, Mar 25, 2006 at 12:43:57PM -0500, Henning Schulzrinne wrote: Indeed. Not only is it small, it isn't where corporate bean counters put their attention, which is air fare, hotel, and per diem. Brian, this is not universally true. With cheaper air fares and not staying in the overpriced Hilton hotel rooms, my IETF65 meeting fee was almost exactly the same as my combined hotel and air fare costs. For those of us not on corporate expense accounts, it's the total amount that matters. Being trapped away from the IETF hotel for one night by the flood, the quality of a nearish (5-10 min drive, probably 1h walk) motel was a little of an eye opener, very similar quality for $69+taxes, and a bigger bathroom. Why the Hilton creates such enormous rooms with such small en-suites is a mystery to me :) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
technical tutorials (was: RE: Moving from hosts to sponsors)
-Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] I don't think that the current meetings are power-point laden summaries, but that would actually be useful. I often end up going to sessions at conferences to find out what a WG is intended to achieve. This only happens at IETF in the BOFs. I am not too worried about ending up with a trade show. The real danger as I see it is adding a speaker track or having open access to the trade show. A secondary risk is that people who want to go to attend the IETF would get seconded to man the booth. I believe that I made this proposal in the past, in a plenary session a while ago, when numbers in the IETF particpation were the issue. Discussions hold then led to the edu track, which is however focused on IETF process and not on technical or tutorial content. I do not see why should not the IETF offer a full Sunday track of tutorials with technical content. Why should one go to a industry conference or trade show to hear what is going on in an IETF WG, when the principal contributors (WG chairs, editors) who usually give these talks are all attending the IETF meetings? Having a full Sunday track of tutorials would not only attract new people to come to the IETF and help them justify to their employers and to themselves the cost of the travel, but also improve the level of understanding of the technical material in the WGs, increasing the chances that new attendees would become active participants in a shorter time. We can even play with different fees structure (conference only, tutorial only, conference + tutorial) to help people optimize their costs. The extra money resulting from the tutorial fees and increased participation would lower sponsoring costs, and hopefully the meeting fees for the technical contributors. Dan ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
On Sun, 26 Mar 2006, Tim Chown wrote: On Sat, Mar 25, 2006 at 12:43:57PM -0500, Henning Schulzrinne wrote: Indeed. Not only is it small, it isn't where corporate bean counters put their attention, which is air fare, hotel, and per diem. Brian, this is not universally true. With cheaper air fares and not staying in the overpriced Hilton hotel rooms, my IETF65 meeting fee was almost exactly the same as my combined hotel and air fare costs. For those of us not on corporate expense accounts, it's the total amount that matters. Being trapped away from the IETF hotel for one night by the flood, the quality of a nearish (5-10 min drive, probably 1h walk) motel was a little of an eye opener, very similar quality for $69+taxes, and a bigger bathroom. Why the Hilton creates such enormous rooms with such small en-suites is a mystery to me :) The hotel was built by Trammell Crow and has a been a loews, wyndham and now a hilton (but only for 3 months). So, while hilton hotels inc gets some blame for certain things (rooms had better soap when it was wyndham) it hardly assumes blame for all of them. -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
First, I think much of my concern is a due to having no clue what a user principal name is in the context of this draft. It seems to be some identifier used in some directory service. The only clue given in the document is that it is a name form defined by Microsoft. It is odd that there is no reference, not even an informative one, to this definition. As I am lacking clue, I doubt I can offer appropriate text provding the (necessary) clue that independent developers will need to produce an interoperable implementation. But I will, nevertheless, try in hopes it help you and other better understand my concerns. It will likely need to be reworked by the I-D authors based upon their understanding of what a UPN is. At 08:47 AM 3/22/2006, Russ Housley wrote: Kurt: Okay. I think I get your point. I'll try one more time, but if that does not satisfy you, then you will have to respond with proposed text. I'm trying to address Pasi's comment too. Based on updates from a previous comment, the document will say: The domain_name parameter, when specified, SHALL contain a domain name in the preferred name syntax, as specified by RFC 1123. I would suggest instead: The domain_name parameter, when specified, provides a DNS [RFC1034][RFC2181] host name [RFC1123] represented as an ASCII [ASCII] character string conforming to the domain production provided in Section 2.1 of [draft-zeilenga-ldap-cosine]. It is also noted that applications supporting Internationalized Domain Names SHALL use the ToASCII method [RFC3490] to produce label components of this domain production. I think that this resolves your concern about the encoding of domain_name. I propose the following text to handle the same concern for user_principal_name: The user_principal_name parameter, when specified, SHALL contain an Unicode UPN, encoded as a UTF-8 string. Now, for the rest: This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate. For instance, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that the server processes the user_principal_name with a stringprep profile [STRINGPREP] appropriate for the identity in question, such as Nameprep [NAMEPREP] for the portion domain portion of UPN and SASLprep [SASLPREP] for the user portion of the UPN. I note that SASLprep is case-insensitive and hence may not be appropriate for the user portion of a UPN. I note that Nameprep has to be applied component wise. I also think it odd to allow both toUnicode and toASCII domain component forms on the wire. The specification should choice one or the other (I recommend the latter). However, based in part with off line discussions with Stefan, I suggest. This document does not detail the syntax or semantics of a User Principal Name beyond that it is a string of UTF-8 encoded Unicode characters (with no required normalization) where at least of these characters is the COMMERCIAL AT (@ U+0040) character. The syntax and semantics of User Principal are application specific. It is expected that applications calling for the use of this extension detail these syntax and semantics. I note that I believe independent developers have near-zero chance of producing an interoperable implementation of this I-D (as is, or as modified by the various suggestions). The developer, it seems, has to depend on knowledge gained outside of this I-D. Regards, Kurt Russ At 10:04 AM 3/22/2006, Kurt D. Zeilenga wrote: At 12:03 AM 3/22/2006, Russ Housley wrote: Kurt: Would text like the following (which is largely stolen from draft-ietf-tls-psk) solve your concern: No. While the language does address part of the question: how/where canonical of the user_principal_name string is performed? it neither addresses this question: how/where canonical of the domain_name string is performed? nor address the question: what character set/encoding is used on the wire in transferring these character strings? I also suspect that the selection of SASLprep here, which is intended to be used for simple usernames and passwords, is appropriate for all of the user_principal_name string. My understanding is that the user_principal_name is composed of both a simple username part and a domain part. Components of the latter likely should instead be prepared by nameprep (if allowed to carry IDNA components). Also, as the user part of the user_principal_name is, it appears from casual examination of various MS documents, to be case insensitive, SASLprep should not be used. Kurt This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate. For instance, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that the server processes the user_principal_name
Re: technical tutorials (was: RE: Moving from hosts to sponsors)
--On Sunday, 26 March, 2006 14:50 +0200 Romascanu, Dan \\(Dan\\) [EMAIL PROTECTED] wrote: I believe that I made this proposal in the past, in a plenary session a while ago, when numbers in the IETF particpation were the issue. Discussions hold then led to the edu track, which is however focused on IETF process and not on technical or tutorial content. I do not see why should not the IETF offer a full Sunday track of tutorials with technical content. Why should one go to a industry conference or trade show to hear what is going on in an IETF WG, when the principal contributors (WG chairs, editors) who usually give these talks are all attending the IETF meetings? Having a full Sunday track of tutorials would not only attract new people to come to the IETF and help them justify to their employers and to themselves the cost of the travel, but also improve the level of understanding of the technical material in the WGs, increasing the chances that new attendees would become active participants in a shorter time. We can even play with different fees structure (conference only, tutorial only, conference + tutorial) to help people optimize their costs. The extra money resulting from the tutorial fees and increased participation would lower sponsoring costs, and hopefully the meeting fees for the technical contributors. Dan, I see one major problem with this. I tried to raise it with the EDU team before Dallas but, other than one set of offline comments from an individual, have gotten no response. Despite all of the noise in the IPR WG, the biggest risks to a standards body involve claims that the review and approval process have been captured or manipulated by particular interests, causing the documents that are produced to reflect those manipulations rather than open and balanced community consensus. A tutorial whose subject matter is how to get things done in the IETF -- how we are structured, how we do business, the tools we use, and even what one needs to know technically and structurally to write an I-D or RFC -- are not problematic. But, as soon as we start giving technical tutorials that related to areas that are under standardization, there is a risk of someone later claiming that the tutorial content was biased in one way or another that impacted the standardization choices we made. That would be extremely bad news... possibly of the variety that could have the EDU team or the IESG neck-deep in lawyers. So, if there are to be technical tutorials, I suggest that you start working on an organizational structure that would keep the decisions about which sessions to hold and their content at arms-length or further from anyone with decision-making leadership in the IETF. Even then, there are risks. But a decision made by an EDU team that operates under even general IESG supervision, or with a lecturer who is involved in the standards process and who is taking positions there (or is associated with a company that is doing so), are really poor ideas if we want to preserve both the fact and appearance of fairness in the standards process. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the iab net neutrality
On 3/25/06 7:47 PM, Spencer Dawkins [EMAIL PROTECTED] wrote: So my point was, I'd really like to take a chance on some IAB statements about things that need to be stated about our architecture. They might be ignored. Would the result be any worse? This is a somewhat bothersome case, because the IAB *did* issue an RFC explaining what many of the problems were with Unilateral Network Self-Address Fixing (i.e. STUN). They included a list of conditions they felt that an UNSAF protocol had to meet in order to be published, including a description of a transition mechanism away from itself and towards something more robust. I don't know what more the IAB could have done in order to kill what I think is a clearly pathological approach to NAT traversal (and I chaired the working group that standardized it, so I accept a great deal of responsibility for this mess), but if putting out a document that says These are the reasons that this isn't a good protocol isn't enough, well, I'm not sure. But it seems to me that trying to fix it this late in the process (my other .sig is software longa, hardware brevis) has less to do with architecture and more to do with oncology. At any rate, I do think that in this case the IAB did do their job and it was the rest of us louts who messed up. And I'll tell you where I think it happened: when we accepted the idea that something might be transitional and would eventually go away. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
