Re: Speaking of VAT
Original Message - From: John R Levine jo...@taugh.com To: Yoav Nir y...@checkpoint.com Cc: ietf@ietf.org Sent: Sunday, August 04, 2013 10:47 PM Subject: Re: Speaking of VAT Ray said the tax guys told him the IETF would get back about half of the VAT it paid. That's unrelated to what anyone can reclaim. My understanding is that Germany has reciprocal VAT agreements with a bunch of countries so if your employer is in one of those countries it may be able to reclaim, but since the US isn't one of them I haven't looked in detail. John VAT is a European Union tax that all member states are required to levy on the supply of goods and services, although there is flexibility about the rate it is levied at and what it is levied on. As a VAT-registered business, mandatory when turnover exceeds a threshold, I tot up the VAT I have charged and the VAT I have paid and the difference goes to (or comes back from) the tax authorities. This applies across the European Union so there is no problem about where the VAT is paid - any European Union country will do - and equally, VAT must be charged whereever a supply is made. There is no requirement to charge VAT on the export of goods outside the European Union - technically, they are zero-rated - but in general, it must be charged on the export of services. The exemption on the export of goods has generated a lot of fraud in the past few years, especially on high value goods such as computer chips, and so has attracted the attention of the tax authorities. Only businesses can reclaim the tax - private individuals cannot. VAT as implemented in the European Union is an administrative and bureaucratic nightmare, generating work for armies of lawyers, accountants and administrators. I would be wary of extrapolating any aspect of European VAT to taxes of the same name in other parts of the world (smile - things could be worse:-). The European Union's VAT was the first, I think. Tom Petch R's, John
Re: procedural question with remote participation
On 08/04/2013 02:54 PM, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. I agree that remote people should see the slides at the same time as local people, except that I think that in both cases this should be well before the meeting. The slides shouldn't be shown at the meeting unless needed to illustrate a point of active discussion. People keep acting as if the purpose of these meetings - the reason people spend thousands of euro and travel thousands of km - is to watch slides. Keith
Re: procedural question with remote participation
On 06/08/13 14:08, Keith Moore wrote: On 08/04/2013 02:54 PM, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. I agree that remote people should see the slides at the same time as local people, except that I think that in both cases this should be well before the meeting. The slides shouldn't be shown at the meeting unless needed to illustrate a point of active discussion. People keep acting as if the purpose of these meetings - the reason people spend thousands of euro and travel thousands of km - is to watch slides. interesting.. out of pure curiosity, People keep acting, you mean, who? Thanks, Aaron PS: this whole tread is about the key word slides. If one of the key purposes is NOT about presentation, what are talking about here? plz correct me, if I got it wrong... Keith
Re: Speaking of VAT
My understanding is that Germany has reciprocal VAT agreements with a bunch of countries so if your employer is in one of those countries it may be able to reclaim, but since the US isn't one of them I haven't looked in detail. John VAT is a European Union tax that all member states are required to levy on the supply of goods and services, although there is flexibility about the rate it is levied at and what it is levied on. ... Yes, but there are also reciprocal agreements separate from the usual credit for VAT paid, with non-EU countries including Israel. The page that Ray pointed to describes this. R's, John
Re: procedural question with remote participation
to clarify, imho: presentation != slides making the best out of IETF meetings for both f2f and remote participants is hard and yet worth our try. back to our slides shipping tread, everybody has own opinion toward whether I prefer/believe the slides should be uploaded earlier or not so, and obeying our own principle when doing our own presentation materials is definitely appreciated, but don't force it upon others please. (of course WG chairs can recommend WG presenters to follow the same agenda for better coordination within the group, and in that case f2f and remote participants can be duly notified via WG mailing list, in advance) Thanks, Aaron On 06/08/13 14:49, Aaron Yi DING wrote: On 06/08/13 14:08, Keith Moore wrote: On 08/04/2013 02:54 PM, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. I agree that remote people should see the slides at the same time as local people, except that I think that in both cases this should be well before the meeting. The slides shouldn't be shown at the meeting unless needed to illustrate a point of active discussion. People keep acting as if the purpose of these meetings - the reason people spend thousands of euro and travel thousands of km - is to watch slides. interesting.. out of pure curiosity, People keep acting, you mean, who? Thanks, Aaron PS: this whole tread is about the key word slides. If one of the key purposes is NOT about presentation, what are talking about here? plz correct me, if I got it wrong... Keith
Re: procedural question with remote participation
On 08/06/2013 09:08 AM, Keith Moore wrote: On 08/04/2013 02:54 PM, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. I agree that remote people should see the slides at the same time as local people, except that I think that in both cases this should be well before the meeting. The slides shouldn't be shown at the meeting unless needed to illustrate a point of active discussion. People keep acting as if the purpose of these meetings - the reason people spend thousands of euro and travel thousands of km - is to watch slides. Hi Keith, I think this sort of misses the point. At least for me as a remote participant. I'm not interested in arguing about whether slides are good or bad. I am interested in following (and being involved) in the WG meeting. When there are slides I want to be able to see them clearly from my remote location. Having them integrated with Meetecho works fine. Having slides and other materials available to download ahead of time is also OK. I can work with what is available, but having slides brought to the meeting on USB (it happens) does me no good. Also people using pointing devices, that can't be seen remotely, to point to areas on each slide doesn't help. As of today when the slides are available (or if there are no slides and just talk) I can follow WG meetings quite well. Being able to actively engage in any discussion remotely is, IMO, pretty much limited to the mailing lists. Getting involved in an active discussion at a WG meeting remotely is currently difficult at best and impossible at worst. I'm all in favor of discussions in WG meetings, but from where I sit we still have a ways to go to fully integrate remote participants. Making slides available soon enough to be viewed by remote attendees during the meeting seems like an achievable step towards better integration of remote participants. The usefulness of doing this is also independent of whether the slides are for a presentation or to illustrate a point of discussion. As Ted noted, What is important is that remote people see the slides at the same time as local people. That is the point. -Andrew
Re: [iaoc-rps] RPS Accessibility
On 8/5/2013 2:15 AM, Dan York wrote: On the topic of badge-sensing at the mic, I seem to recall that we had this working at an IETF sometime back in the RAI working groups. It was maybe 4 or 5 years ago and I think it may have been some student(s) under Henning Schulzrinne at Columbia... but I am not sure about that. I remember that when you went to the mic you put your badge up to this sensor and your name appeared in the jabber room. We used it in several of the RAI sessions at that IETF. Unfortunately I don't remember how well it worked or why it wasn't continued. There may be someone out there who can provide some insight. (And if it was Henning's students we can just drop him a note.) It was an experiment. It was awkward and inaccurate. It also raised basic privacy concerns, what with wearing something that can be tracked as you move around. An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [iaoc-rps] RPS Accessibility
On the topic of badge-sensing at the mic, I seem to recall that we had this working at an IETF sometime back in the RAI working groups. It was maybe 4 or 5 years ago and I think it may have been some student(s) under Henning Schulzrinne at Columbia... but I am not sure about that. I remember that when you went to the mic you put your badge up to this sensor and your name appeared in the jabber room. We used it in several of the RAI sessions at that IETF. Unfortunately I don't remember how well it worked or why it wasn't continued. There may be someone out there who can provide some insight. (And if it was Henning's students we can just drop him a note.) Dan -- Dan York y...@isoc.org +1-802-735-1624 skype:danyork http://twitter.com/danyork On Aug 2, 2013, at 10:26 AM, Paul Aitken pait...@cisco.com wrote: I've remotely participated in several IETFs. I find that the biggest problem with remote attendance is the lack of visual cues. I've come to realise just how important these are in a meeting. -are people paying attention, are they interested / confused / distracted / bored? Also there's no way for local attendees (in the WG room) to know that remote attendees are at the mic and whose turn it is to speak. There's been some discussion on the 87attendees mailer about badge sensing at the mic - whether QR codes, NFC, or RFID. This could help remote attendees too. eg, see what they did with NFC + mic here: http://www.5thbar.me/blog/2012/09/14/nfc-enabled-badges-at-the-5thbar-mobile-marketing-forum/ P. ___ iaoc-rps mailing list iaoc-...@ietf.org https://www.ietf.org/mailman/listinfo/iaoc-rps
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On 7/29/13 4:54 AM, Phillip Hallam-Baker hal...@gmail.com wrote: There are existing specs that does what CBOR does just as well that have actual users. Some of these were approached, and none of them thought that having a standard for their format was worth the amount of heartache that dealing with the IETF would entail. If you can get one of those communities interested, that would be cool. There are requirements that the individuals proposing this chose not to address. Re-enumerating those for this discussion might be useful. -- Joe Hildebrand
Re: procedural question with remote participation
If the WG/session chairs did not receive the slides at least a few days prior to the meeting, then it is really hard for the WG chairs to make sure that the slides support a discussion, rather than a presentation. Given that we have meetings on Friday morning, and some people are very busy during the week, and travel time can be 24h for some trips, asking that the chair has received the slides *a week* before the WG session, being Friday morning, seems to actually be cutting it really close. If a discussion leader can not get some slides into the WG chairs' inbox by the Friday morning before the IETF meeting, then I question whether the WG chair should give them any time. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
Re: [iaoc-rps] RPS Accessibility
Dave Crocker d...@dcrocker.net wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. +1. And move the microphones to the people, rather than the other way around. We can easily have three or four microphones that can play leap-frog around the room. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpbuKd5jXtF2.pgp Description: PGP signature
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On Tue, Aug 6, 2013 at 11:41 AM, Joe Hildebrand hil...@cursive.net wrote: On 7/29/13 4:54 AM, Phillip Hallam-Baker hal...@gmail.com wrote: There are existing specs that does what CBOR does just as well that have actual users. Some of these were approached, and none of them thought that having a standard for their format was worth the amount of heartache that dealing with the IETF would entail. If you can get one of those communities interested, that would be cool. There are requirements that the individuals proposing this chose not to address. Re-enumerating those for this discussion might be useful. The issue here is whether this proposal should be an IETF Proposed STANDARD. I think that is nuts and I would think it just as much nuts if it was my proposal. We have no real world implementation experience by which I mean using it in a protocol and not writing some python Usually when the IETF publishes an algorithm it is given INFORMATIONAL or EXPERIMENTAL status. That is what originally happened with JSON, RFC 4627 has INFORMATIONAL status despite the fact that at the time it was written there was a lot of implementation. Using the individual submissions track as a way to circumvent working group process when there is an actual IETF JSON working group seems completely wrong to me. For the record, the issues I see are: 1) This is an entirely new encoding and semantics. It is not JSON in binary which is what we actually need. 2) No support for tag compression. 3) No support for decimal floating point. 4) Its all or nothing, no layering. The first one is my main complaint. I want to be able to use the binary and text JSON encodings interchangeably and not have the upper layers to have to bother with it at all. That is why I designed a system where a single reader can read binary and text without the need for any additional state (beyond tracking how the current item is encoded.) What I like in JSON is the lack of features and the fact that JSON covers 95% of all my needs as is. All I want to add in to get to 100% features are the ability to encode floating point without loss and the ability to efficiently encode binary blobs. -- Website: http://hallambaker.com/
Re: procedural question with remote participation
On 2013-08-06, at 10:26, Aaron Yi DING aaron.d...@cl.cam.ac.uk wrote: to clarify, imho: presentation != slides In my experience, slides are mainly useful: 1. To convey information which is difficult to express accurately by voice only (e.g. graphs, names of drafts, big numbers) 2. To distract the e-mail-reading audience in the room so that they look up and pay attention. An example of (2) can be found in http://www.ietf.org/proceedings/87/slides/slides-87-dnsop-8.pdf where I presented a one-slide problem statement that consisted entirely filled with an xkcd cartoon. Once the room is suitably filled with hilarity, it's much easier to enrage people with your stupid idea. I don't think that having slides available in advance helps significantly with (1) in an ietf context (where we are continuing a conversation from a list, and not generally introducing new material). (2) is not really pertinent for a remote audience (if they've bothered to attend at all, you can surely assume they are paying attention.) Many people use slideware as a teleprompter so that they can remember what to say at the mic. I've done that before. I'm not proud of it. The best outcome at a working group meeting is that, as a presenter, you spend most of your time listening rather than talking. If the mic line is empty, you probably should not have been on the agenda. Joe
Re: procedural question with remote participation
Hey Joe, On 8/6/13 7:41 PM, Joe Abley wrote: An example of (2) can be found in http://www.ietf.org/proceedings/87/slides/slides-87-dnsop-8.pdf where I presented a one-slide problem statement that consisted entirely filled with an xkcd cartoon. Once the room is suitably filled with hilarity, it's much easier to enrage people with your stupid idea. I don't think that having slides available in advance helps significantly with (1) in an ietf context (where we are continuing a conversation from a list, and not generally introducing new material). (2) is not really pertinent for a remote audience (if they've bothered to attend at all, you can surely assume they are paying attention.) What? People remotely can't read email? Heck we can do more than that. We can cook a meal. Try that while an IETF is going on. Many people use slideware as a teleprompter so that they can remember what to say at the mic. I've done that before. I'm not proud of it. But if those lines contain *questions*, it gets you to the point where there is discussion, which is just fine, as you point out here: The best outcome at a working group meeting is that, as a presenter, you spend most of your time listening rather than talking. If the mic line is empty, you probably should not have been on the agenda. 100% agree. Eliot
Re: procedural question with remote participation
On Aug 6, 2013, at 1:41 PM, Joe Abley jab...@hopcount.ca wrote: In my experience, slides are mainly useful: 1. To convey information which is difficult to express accurately by voice only (e.g. graphs, names of drafts, big numbers) Yup. 2. To distract the e-mail-reading audience in the room so that they look up and pay attention. YES! (Crap, I thought we were supposed to keep that purpose a secret!) And no way am I uploading my jokes in advance and having people see them in advance - it ruins the joke completely! Sheesh, they're barely funny enough as is. An example of (2) can be found in http://www.ietf.org/proceedings/87/slides/slides-87-dnsop-8.pdf where I presented a one-slide problem statement that consisted entirely filled with an xkcd cartoon. Huh, who knew DNS Ops was rocket science? :) (I like the hack idea, btw... mostly because I like your xkcd cartoon, of course) Many people use slideware as a teleprompter so that they can remember what to say at the mic. I've done that before. I'm not proud of it. Yeah me too, but I'd prefer people pay attention to what I say, rather than the text on the slides. -hadriel
Re: procedural question with remote participation
On 08/06/2013 11:06 AM, Andrew Feren wrote: On 08/06/2013 09:08 AM, Keith Moore wrote: On 08/04/2013 02:54 PM, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. I agree that remote people should see the slides at the same time as local people, except that I think that in both cases this should be well before the meeting. The slides shouldn't be shown at the meeting unless needed to illustrate a point of active discussion. People keep acting as if the purpose of these meetings - the reason people spend thousands of euro and travel thousands of km - is to watch slides. Hi Keith, I think this sort of misses the point. At least for me as a remote participant. Actually I think the desire to get slides out early largely misses the point. Or at least, it's an effort optimizing what should be the rare case. I fully agree that slides should be easily available to both local and remote participants well prior to any meeting in which a presentation will be made. (Say a plenary session where presentations are normal and appropriate.) While speakers might like to revise their slides at the last minute, there's no reason why they shouldn't be expected to upload preliminary slides well in advance (because the key to an effective presentation is good preparation, after all) and a revised version (if necessary) later. This isn't at all rocket science, and there's no reason why it should not be done. But if we really want to make remote participation effective, we need to figure out better ways to involve remote participants in _discussions_ - not only in plenaries, WG meetings, BOFs, etc., but also in hallway and bar conversations. Having a local speaker read something from a laptop that was typed into a Jabber session by a remote participant is better than nothing. But surely we can do better. As of today when the slides are available (or if there are no slides and just talk) I can follow WG meetings quite well. Being able to actively engage in any discussion remotely is, IMO, pretty much limited to the mailing lists. Getting involved in an active discussion at a WG meeting remotely is currently difficult at best and impossible at worst. It used to be the case that Internet access at IETF meetings was flaky, either because of the wireless network or because of the network connection or both. More recently the performance of the meeting Internet access has been stellar. If we put the same kind of effort into facilitating remote participation in discussions, I suspect we could move from difficult at best and impossible at worse to works well. Of course, it might take awhile, but it's those very kinds of discussions that are so essential to broad consensus that (when it works) makes our standards effective. The fact that it doesn't work well now is not a good argument for not making it work well in the future. (We're supposed to be creating the future, after all. That's our job.) It's also the case that the fact that facilities for involving remote participants in conversation haven't historically worked well, is used as a justification for continuing to have this dysfunctional style of conducting working group meetings, thus making very poor use of local participants' time and money. I'm all for making presentation slides available to local and remote participants well before the meeting. But if we're only concerned with making presentation slides available, we're selling ourselves very short. That's the point I'm trying to make. Keith
Re: procedural question with remote participation
On 2013-08-06, at 14:00, Hadriel Kaplan hadriel.kap...@oracle.com wrote: An example of (2) can be found in http://www.ietf.org/proceedings/87/slides/slides-87-dnsop-8.pdf where I presented a one-slide problem statement that consisted entirely filled with an xkcd cartoon. Huh, who knew DNS Ops was rocket science? :) (I like the hack idea, btw... mostly because I like your xkcd cartoon, of course) Of course! And now people who aren't even following dnsop are reading the slides, and maybe even the draft. It's a triumph of social engineering. :-) Joe
Re: procedural question with remote participation
On Aug 6, 2013, at 10:52 AM, Eliot Lear l...@cisco.com wrote: But if those lines contain questions, it gets you to the point where there is discussion, which is just fine, as you point out here: The best outcome at a working group meeting is that, as a presenter, you spend most of your time listening rather than talking. If the mic line is empty, you probably should not have been on the agenda. Dear Eliot and Joe, The context of local conversations often use shorthand references to the material presented rather than restating the content to ensure remote participants understand what is being said. The IETF should devise a strategy able to virtualize both the local protector and PA in the event the venue no long has access to the Internet but where the meetings are still able to proceed. Ensure remote participants are not considered secondary. If fact, paying some access fee (that should be able to avoid VAT) might be reasonable. Regards, Douglas otis
Re: [iaoc-rps] RPS Accessibility
On 2013-08-06, at 11:27, Dave Crocker d...@dcrocker.net wrote: On 8/5/2013 2:15 AM, Dan York wrote: [...] I remember that when you went to the mic you put your badge up to this sensor and your name appeared in the jabber room. ... and the main screen in the room, if we're thinking about the same experiment. I seem to think it might have been in Hiroshima. It was an experiment. It was awkward and inaccurate. It also raised basic privacy concerns, what with wearing something that can be tracked as you move around. I thought it was less awkward and inaccurate than relying on poly-accented and rushed (or missing) announcements of name and affiliation through the microphone. It was an improvement for jabber scribes, wg chairs trying to do minutes, remote participants and people in the room who are interested in who is talking, but not interested enough to stand up and demand that the name and affiliation be repeated. I remember the privacy concerns being expressed, but I also have been subscribed to more XXattendees mailing lists than I care to remember, and I had compartmentalised both sets of complaints into the same bucket that usually makes me unsubscribe from XXattendees by Tuesday. The NFC badge idea was a good one, I think, and I think it should happen again (even if it's opt-in at registration time, to reduce anxiety for those worried about their loss of privacy in a public meeting.) Or perhaps future IETFers.app releases could talk using bluetooth to a transponder duct-taped to the mic stand and realise the same outcomes (and if you don't like that, you can always touch no in the appropriate place on your phone). Joe
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On 8/6/13 11:34 AM, Phillip Hallam-Baker hal...@gmail.com wrote: The issue here is whether this proposal should be an IETF Proposed STANDARD. standards-track != standard, right? I think that is nuts and I would think it just as much nuts if it was my proposal. We have no real world implementation experience by which I mean using it in a protocol and not writing some python When I parse your words closely, I see you calling the idea nuts, but the emotional reaction I had was that you had called *me* nuts. Regardless, this seems a little out of proportion to what I thought was a relatively polite attempt at dialog. I'm worried that this kind of interaction is exactly the sort of thing that scares new communities away from participating here. Usually when the IETF publishes an algorithm it is given INFORMATIONAL or EXPERIMENTAL status. That is what originally happened with JSON, RFC 4627 has INFORMATIONAL status despite the fact that at the time it was written there was a lot of implementation. I would argue that if 4627 had received the more-thorough review that would have come from being on standards track, it might not have had as many problems as we're finding that it does. Using the individual submissions track as a way to circumvent working group process when there is an actual IETF JSON working group seems completely wrong to me. First, this isn't JSON, even though interop with JSON was a goal. Second, if the JSON wg wanted to recharter with a broader mission that included CBOR and other similar protocols, that might be interesting to me. I don't get the sense from what I've seen in that group that there would be enough energy for that, but that is obviously not for me to decide. Third, I think I said in my long message that I wouldn't mind having a working group look at this, so I'm not sure why you'd accuse me of circumventing process here. For the record, the issues I see are: 1) This is an entirely new encoding and semantics. It is not JSON in binary which is what we actually need. To me, it appears to be a proper superset of the parts of JSON that are safe to use. 2) No support for tag compression. That's an interesting requirement, and one that I think could be added to the design if there were others that felt motivated to help. I think I can see a way that it could be added later: create a new tag that precedes a map of string-to-int conversions. However, my intuition is that this wouldn't have radically better behavior than gzip, and so I'd like to see some numbers to prove that the complexity was worthwhile. 3) No support for decimal floating point. Section 2.4.3 describes decimal fractions. Can you describe what other behavior you'd like? Or are you arguing that you'd like to see that moved to being a core type? 4) Its all or nothing, no layering. Could you say more about that? I see the tagging system as being exactly a layering system, where you are explicitly invited to ignore any tag you don't implement. The first one is my main complaint. I want to be able to use the binary and text JSON encodings interchangeably and not have the upper layers to have to bother with it at all. I think I understand this. I could see where my CBOR event-based parser could also take JSON in, and generate the exact same events. I might even do that as a proof of concept. Could you say more about what in CBOR you think violates this? Understandably, some type information will be lost converting CBOR-to-JSON, but that will be true for anything that we come up with in this space, I think. What I like in JSON is the lack of features and the fact that JSON covers 95% of all my needs as is. All I want to add in to get to 100% features are the ability to encode floating point without loss and the ability to efficiently encode binary blobs. I'd add dates to this, but I mostly agree with you. CBOR, to me, was close enough to what I wanted, explained in a way that made it easy to implement, and I could ignore the bits that I didn't need for my use cases. I got over the fact that it was different than what I had originally wanted, that it has some complexifying features like streaming (added at the request of the community), and that we couldn't get any of the existing players in the space to bring their work to us. -- Joe Hildebrand
Re: RPS Accessibility
Could be an app that put you in the queue and used your laptop/tablet/smartphone microphone to get the audio. On Tuesday, August 6, 2013, Michael Richardson wrote: Dave Crocker d...@dcrocker.net javascript:; wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. +1. And move the microphones to the people, rather than the other way around. We can easily have three or four microphones that can play leap-frog around the room. -- Michael Richardson mcr+i...@sandelman.ca javascript:;, Sandelman Software Works
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
2) No support for tag compression.
(I assume this was about map keys, not about tags.)
That's an interesting requirement, and one that I think could be added to
the design if there were others that felt motivated to help. I think I
can see a way that it could be added later: create a new tag that precedes
a map of string-to-int conversions.
I'd probably do it the other way around:
tagN([{1: foo, 2: bar}, ...abbreviated data item...])
Where an abbreviated data item of the form
[1, 2, 3, {1: beer, 2: wine, baz: 1}, 5, 6]
would then be interpreted as
[1, 2, 3, {foo: beer, bar: wine, baz: 1}, 5, 6]
Yes, processing of this kind is easy to add as a tag.
If the first parameter is instead a URI (preferably ni: scheme), it could save
carrying around a large dictionary.
However, my intuition is that this wouldn't have radically better behavior
than gzip, and so I'd like to see some numbers to prove that the
complexity was worthwhile.
I share that intuition. CBOR is intended to be useful also in those
environments where running a full compression algorithm is impractical; here
such a scheme could still have benefits.
The first one is my main complaint. I want to be able to use the binary
and text JSON encodings interchangeably and not have the upper layers to
have to bother with it at all.
(The applications I have in mind use media types, but:)
I think I understand this. I could see where my CBOR event-based parser
could also take JSON in, and generate the exact same events. I might even
do that as a proof of concept. Could you say more about what in CBOR you
think violates this?
Well, if you don't have a media type, and don't know whether you'll get a JSON
text or a CBOR data item, you may need to mechanically distinguish them.
E.g., the following six characters can occur at the start of a JSON text.
All are valid as start (or only) byte of a CBOR data item:
ByteJSON meaningCBOR interpretation
%x20 ; Space -1
%x09 ; Horizontal tab 9
%x0A ; Line feed or New line 10
%x0D ; Carriage return 13
%x5B ; [ left square bracket starts byte string
%x7B ; { left curly bracketstarts UTF-8 string
(Well, for any valid JSON texts, heuristics might tell you the string data
items a CBOR parser sees are unrealistically large.)
If a CBOR application does require initial signature bytes for self-description
purposes, I would suggest using something like
0xd8 0xf8 ...data item...
which decodes as tag248(data item); we could define 248 as a no-op tag.
(I'm still working on your other message -- lots of juicy input, thank you!)
Grüße, Carsten
Re: [iaoc-rps] RPS Accessibility
On Aug 6, 2013, at 11:27 AM, Dave Crocker d...@dcrocker.net wrote: It was an experiment. It was awkward and inaccurate. It also raised basic privacy concerns, what with wearing something that can be tracked as you move around. Ironically, this IETF everyone who stayed at the Intercontinental was walking around with an RFID key in their pocket the whole meeting. How many of us put them in faraday cages? I thought the experiment in Hiroshima went well, and wish we had made it standard practice. It is _really_ hard to get people to say their names consistently in a way that is intelligible to the note-taker; I would go so far as to say that this is unachievable.
Re: [iaoc-rps] RPS Accessibility
On Aug 6, 2013, at 11:27 AM, Dave Crocker d...@dcrocker.net wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. I would not mind this system intensely, but bear in mind that it requires everybody to bring a mobile device of some sort that can be used to do this registration, and they will have to keep that device out and active during all meetings. If their battery dies, they can no longer participate, or will require exception handling.
Re: [iaoc-rps] RPS Accessibility
Ironically, this IETF everyone who stayed at the Intercontinental was walking around with an RFID key in their pocket the whole meeting. How many of us put them in faraday cages? I put all of my cards in a faraday cage, but perhaps that's just me, and because I carry an RFID passport card. R's, John
Re: procedural question with remote participation
On 06/08/13 19:03, Keith Moore wrote: But if we're only concerned with making presentation slides available, we're selling ourselves very short. That's the point I'm trying to make. Keith Hi Keith, Thanks for clarifying it - agree with you fully on this point. Keeping a clear goal in mind helps improve our current practice, and I pretty much like what Joe hinted: On 06/08/13 18:41, Joe Abley wrote: The best outcome at a working group meeting is that, as a presenter, you spend most of your time listening rather than talking. If the mic line is empty, you probably should not have been on the agenda. Joe How to get remote participants involved in meaningful discussion deserves our close attention, besides to improve the experience for f2f participants, e.g., presenters. (IMO, when to upload slides and how to coordinate is a WG specific issue and WG/session chairs can define a rule of conduct in their own meetings so it works best there, for both remote and f2f) Cheers, Aaron PS: I personally find it rather funny to see people claiming one's own approach works better and so forth implicitly indicating they really understand what remote/f2f participants need, and even so, we others should follow... which somehow reminds me Dave Crocker once joked in another thread that almost everyone claims that they are a better than average driver ;)
Re: procedural question with remote participation
On 2013-08-06, at 15:35, Aaron Yi DING aaron.d...@cl.cam.ac.uk wrote: PS: I personally find it rather funny to see people claiming one's own approach works better and so forth implicitly indicating they really understand what remote/f2f participants need, For the record, I have zero experience consuming my own in-person presentations whilst attending remotely. I will say that Dan York did a stand-up job in dnsop last week channeling jabber chatter to the microphone. Joe
Re: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
On 8/6/13 1:11 PM, Carsten Bormann c...@tzi.org wrote: If a CBOR application does require initial signature bytes for self-description purposes, I would suggest using something like 0xd8 0xf8 ...data item... which decodes as tag248(data item); we could define 248 as a no-op tag. Or a no-op simple value; we could easily pick one that did not generate a valid first character for JSON. -- Joe Hildebrand
Re: [iaoc-rps] RPS Accessibility
On 06/08/13 18:31, Michael Richardson wrote: Dave Crocker d...@dcrocker.net wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. +1. +1 too. And move the microphones to the people, rather than the other way around. This is indeed friendly, although standing up to walk a bit is also good, at least f2f participants won't sit on chairs the whole day.. adding this option to the existing one will be nice. Cheers, Aaron -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
Re: [iaoc-rps] RPS Accessibility
On 8/6/2013 12:15 PM, Ted Lemon wrote: On Aug 6, 2013, at 11:27 AM, Dave Crocker d...@dcrocker.net wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. I would not mind this system intensely, but bear in mind that it requires everybody to bring a mobile device of some sort that can be used to do this registration, and they will have to keep that device out and active during all meetings. If their battery dies, they can no longer participate, or will require exception handling. Lean over to a neighbor and ask them to put you into the queue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [iaoc-rps] RPS Accessibility
On 8/6/13 11:58 AM, Joe Abley wrote: For what it's worth (not much) I would miss the line at the mic. There are useful conversations that happen within the line that I think we would lose if the mic followed the speaker, and I also think that pipelining the people at the mic promotes more fluid conversation. But these are minor points, and I'm mainly just waxing nostalgic. I actually think that this is not a small point. The people in line are the people with issues and the ability to hash stuff out quickly is pretty nice. Melinda
Re: [iaoc-rps] RPS Accessibility
On 2013-08-06, at 15:54, Aaron Yi DING aaron.d...@cl.cam.ac.uk wrote: On 06/08/13 18:31, Michael Richardson wrote: And move the microphones to the people, rather than the other way around. This is indeed friendly, although standing up to walk a bit is also good, at least f2f participants won't sit on chairs the whole day.. adding this option to the existing one will be nice. For what it's worth (not much) I would miss the line at the mic. There are useful conversations that happen within the line that I think we would lose if the mic followed the speaker, and I also think that pipelining the people at the mic promotes more fluid conversation. But these are minor points, and I'm mainly just waxing nostalgic. Joe
Re: [iaoc-rps] RPS Accessibility
On Aug 6, 2013, at 1:31 PM, Michael Richardson mcr+i...@sandelman.ca wrote: We can easily have three or four microphones that can play leap-frog around the room. +1 Of course, then we need a facilitator to wrest it away from filibusterers or simply a mechanism for the chairs to mute a mic.
Re: [iaoc-rps] RPS Accessibility
On Aug 6, 2013, at 4:05 PM, Paul Aitken pait...@cisco.com wrote: Could there be a conflict if IETF badges also have RFID tags attached, eg we get Room 1283 at the mic? No. Only known IDs would register. The RFID badge just has a number—it doesn't say Room 1283.
Re: [iaoc-rps] RPS Accessibility
[to no one in particular] Uhhh... I can't tell if you folks are being serious about this idea or not, but in case you are being serious... ISTM there's such a thing as too much technology being a bad thing. If you think technical glitches now-and-then cause issues with remote participants today, wait until physical participants have to deal with glitches in something like this. KISS isn't just a rock-band from the 70's, it's also a useful principle known to many today. If the problem is we don't know who's speaking, then fix that problem. In WGs I go to, both the WG chairs and the jabber scribes regularly yell NAME! if someone forgets to say it. Unlike DNS Ops, this isn't rocket science. Besides, it's not a bad thing to make people get in mic lines, if for no other reason than to have a small barrier threshold for folks to decide it's worth it to say something.[1] -hadriel [1] yes, I recognize the irony in this statement, since I get up to the mic every 15 seconds and say inane things. We can't stop all people like me from wasting meeting time, we can just reduce the number of similar people wasting time. On Aug 6, 2013, at 3:15 PM, Ted Lemon ted.le...@nominum.com wrote: On Aug 6, 2013, at 11:27 AM, Dave Crocker d...@dcrocker.net wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. I would not mind this system intensely, but bear in mind that it requires everybody to bring a mobile device of some sort that can be used to do this registration, and they will have to keep that device out and active during all meetings. If their battery dies, they can no longer participate, or will require exception handling.
Re: [iaoc-rps] RPS Accessibility
On Aug 6, 2013, at 4:37 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: If the problem is we don't know who's speaking, then fix that problem. In WGs I go to, both the WG chairs and the jabber scribes regularly yell NAME! if someone forgets to say it. Unlike DNS Ops, this isn't rocket science. This doesn't work very well. In one meeting where I was scribing this IETF, I had to shout NAME at the same person several times, because he didn't state his name clearly enough for me to be sure I'd gotten it, and so it didn't stick. I hate doing this—I think it's disruptive, and nobody likes getting yelled at. I certainly don't like _having_ to yell.
Re: [iaoc-rps] RPS Accessibility
On 08/06/2013 01:46 PM, Ted Lemon wrote: On Aug 6, 2013, at 4:37 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: If the problem is we don't know who's speaking, then fix that problem. In WGs I go to, both the WG chairs and the jabber scribes regularly yell NAME! if someone forgets to say it. Unlike DNS Ops, this isn't rocket science. This doesn't work very well. In one meeting where I was scribing this IETF, I had to shout NAME at the same person several times, because he didn't state his name clearly enough for me to be sure I'd gotten it, and so it didn't stick. I hate doing this—I think it's disruptive, and nobody likes getting yelled at. I certainly don't like _having_ to yell. Then come up with an alternate proposal. Fixing this problem is non-optional.
Re: [iaoc-rps] RPS Accessibility
On 08/06/2013 12:58 PM, Joe Abley wrote: For what it's worth (not much) I would miss the line at the mic. There are useful conversations that happen within the line that I think we would lose if the mic followed the speaker If the conversations are useful, should they not be happening as part of the meeting?
Re: RPS Accessibility
Brian Rosen b...@brianrosen.net wrote: Could be an app that put you in the queue and used your laptop/tablet/ smartphone microphone to get the audio. I was thinking that too, but I didn't want to get ahead of the problem statement of mic access :-)
Re: [iaoc-rps] RPS Accessibility
On 08/06/2013 04:03 PM, Melinda Shore wrote: On 8/6/13 11:58 AM, Joe Abley wrote: For what it's worth (not much) I would miss the line at the mic. There are useful conversations that happen within the line that I think we would lose if the mic followed the speaker, and I also think that pipelining the people at the mic promotes more fluid conversation. But these are minor points, and I'm mainly just waxing nostalgic. I actually think that this is not a small point. The people in line are the people with issues and the ability to hash stuff out quickly is pretty nice. This only works if the queue is fairly short. When the queue gets longer, and the microphones are in fixed positions, it's not unusual for the topic to jump around from one speaker to the next - and then each speaker has to re-establish what context he's talking about. It's very hard to get convergence under those conditions. I'd actually like to see the microphone queue discipline replaced with something that could handle more than two currently active speakers. Multiple wireless microphones would probably work well enough, if we could change the room setup to make access to those microphones fairer. (though it could still be challenging to incorporate remote speakers into the mix) Keith
Re: RPS Accessibility
On 08/06/2013 01:47 PM, Doug Barton wrote: On 08/06/2013 01:46 PM, Ted Lemon wrote: On Aug 6, 2013, at 4:37 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: If the problem is we don't know who's speaking, then fix that problem. In WGs I go to, both the WG chairs and the jabber scribes regularly yell NAME! if someone forgets to say it. Unlike DNS Ops, this isn't rocket science. This doesn't work very well. In one meeting where I was scribing this IETF, I had to shout NAME at the same person several times, because he didn't state his name clearly enough for me to be sure I'd gotten it, and so it didn't stick. I hate doing this—I think it's disruptive, and nobody likes getting yelled at. I certainly don't like _having_ to yell. Then come up with an alternate proposal. Fixing this problem is non-optional. Apologies if this came off as too terse, or even worse, insulting to Ted. I had a longer response in the works then decided to not go too far into the weeds, and may have trimmed a bit too much. What I've seen in other groups that has worked is a volunteer to record the names of speakers *before* they get to the mic, and then each speaker is announced. Of course that's one more volunteer to find, but it's pretty light duty, and I suspect that some in our crowd would like to have the extra mic time. :) In any case, we must fix these problems. All arguments of the form But it's hard ... are out of scope. Perhaps what is necessary is a solution-focused group to hash out the problem space and come up with workable ideas? I would gladly participate in such a group. Doug
Re: [iaoc-rps] RPS Accessibility
Doug Barton wrote: Ted Lemon wrote: M, Hadriel Kaplan hadriel.kap...@oracle.com wrote: If the problem is we don't know who's speaking, then fix that problem. This doesn't work very well. [...] nobody likes getting yelled at. I certainly don't like _having_ to yell. Then come up with an alternate proposal. Fixing this problem is non-optional. I would neither want to yell at other, nor enjoy being yelled at. Still I might need a reminder. How about a visual cues that would/should work for most participants in a f2f meeting? Supply the chairs (~8 rooms?) with signs at least A4 size, or A3 maybe even using all caps and something like: TELL US YOUR NAME, PLEASE (and affiliation) The chair could raise the sign towards persons at the mic when they forget, slowly moving it up in the air and over the head (and ultimately waving it...) until the message has been received. Maybe attaching such a sign to the MIC from the start could additionally improve the situation. -Martin
Microphone protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As I was watching the conversations in the microphone lines during some of the WG sessions, I thought that we could make a small improvement in the organization that could result in a better meeting. My first observation was that there is two different type of interactions at the microphones: The first one is between a participant and the presenter or the chairs. The second one is participants responding to the first participant, e.g: 1. The presenter proposes some alternatives. 2. Someone at the mic explains her preferences 3. Someone else explains to (2) why she is wrong Generally this triggers a back and forth between (2) and (3) which very often is not fully captured by one of the microphones, because people start talking to each other directly. My second observation was that there is generally 2 microphones, or a multiple of two microphones in each meeting room. So the idea would be to dedicate one microphone for the primary interactions (2) and a different microphone for the secondary interactions (3). We could have the microphone farther from the presenter being the primary microphone and oriented toward the presenter. People line up behind it to interact with the presenter/chairs. The second microphone (which is between the presenter and the primary microphone) is oriented in the opposite direction, i.e. in direction of the primary microphone. People line up behind it to respond to the participant at the primary microphone. I see two potential advantages: - - There is only one line to interact with the presenter, so the chairs do not have to manage two lines. The secondary microphone line stays empty if nobody wants to respond to someone at the primary microphone. and empties each time a new participant reaches the primary microphone. - - Discussions are more natural because participants in a discussion face each other (primary faces presenters, secondary faces primary). With some quick explanations from the chairs at the beginning of a session, the direction of each microphone could be all that is needed to find the role of each microphone. - -- Marc Petit-Huguenin Email: m...@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSAW1WAAoJECnERZXWan7Es/MQAOfGkIzQtCkLMbBRgOVoLUVw sR99BcyQ87b/Gkzcn8JKJFCVt85CC/0GpJVhJ9IATnBkKesJTX4ctmT95/UhFF5U UonOtkdVADq0d1rIHjVVAEwNanuyeyb7JgVUDT4is0gRi3CtkPwzl7hZ+brY3B+p N3/BTCHm9M3iLOtr9SHYEcmogH4IePOlk1p1f4cH4+Gh0dxuSPs4xHthWTsq2pva K2TAQzaORGxBXlaq9BVYiL7UbfnWXcIpVFoe0c9DT2q33XgWStHoTB6Uakt5XkBS L1uSSQGSx0Yk5HXjwQoGo0oqPOnn16kCDYzBH4L3C1F7ZZwX3/LhfsiFNhHjTMDh zR4kOS4DVDKqxaeKdlebGh1c+P5/W4GqlGAgLa7QxQfZu7gBAOs+MG+qw7iZNyU5 8lFi2wivgs292OlPwW1LHID5KwbtIW9dXYtNYlDs5KL1zczHmv1fLHbNcwmdAnA6 ablmVfO3nwnfkZrLExebKBMkEggazipgP4qyDzEhY9zb9RD0sBjmmZyfTUG30GEV z/K79pB7HjdQxyOiksmeq5pVfCfFN/oZmqlnhhStla/QaYQ/67gnopdhX30sEiMm 25XcHBZCkaG5itPWeI8HjuXmqdd4PjhWEenvWN+Ryn3FNAxzZS7D+o3L7Z7lkag1 7pmiTveYpqL5lOpczirq =Ds9N -END PGP SIGNATURE-
RE: RPS Accessibility
I would think any kind of multiple non-fixed microphone setup (maybe even fixed microphones) would need to be tested pretty thoroughly before use, as feedback problems can ruin a discussion. That would include laptop microphones. One way to alleviate this would be to require the use of near-field microphones, mics that only pick up sounds generated close to the mic. They are pretty cheap. Of course, this wouldn't apply to remote participants :) -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, August 06, 2013 8:30 AM To: Michael Richardson Cc: iaoc-...@ietf.org; ietf@ietf.org Subject: Re: RPS Accessibility Could be an app that put you in the queue and used your laptop/tablet/smartphone microphone to get the audio. On Tuesday, August 6, 2013, Michael Richardson wrote: Dave Crocker d...@dcrocker.net javascript:; wrote: An entirely different approach would be to have all speakers make a 'reservation' into a single meetecho (or whatever) online queue, and then get called in order, whether local or remote and independent of what microphone they are at. This gets accurate identification into the online system, with the entry task distributed. +1. And move the microphones to the people, rather than the other way around. We can easily have three or four microphones that can play leap-frog around the room. -- Michael Richardson mcr+i...@sandelman.ca javascript:; , Sandelman Software Works
Re: [iaoc-rps] RPS Accessibility
On Aug 6, 2013, at 4:46 PM, Ted Lemon ted.le...@nominum.com wrote: On Aug 6, 2013, at 4:37 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote: If the problem is we don't know who's speaking, then fix that problem. In WGs I go to, both the WG chairs and the jabber scribes regularly yell NAME! if someone forgets to say it. Unlike DNS Ops, this isn't rocket science. This doesn't work very well. In one meeting where I was scribing this IETF, I had to shout NAME at the same person several times, because he didn't state his name clearly enough for me to be sure I'd gotten it, and so it didn't stick. I hate doing this—I think it's disruptive, and nobody likes getting yelled at. I certainly don't like _having_ to yell. Yeah, the best scenario (other than the person just remembering to say their name), is for the Chairs to remind them - because they have their own microphones so they don't have to actually yell. But another thing that works well is to have the jabber scribe sit in a seat right next to the microphone, because then they don't have to yell either. -hadriel
Re: Berlin was awesome, let's come again
Ulrich Herberg wrote: I think that the heat was exceptional. I have grown up in Munich, and I have rarely ever seen it that hot (either in Munich or Berlin). Maybe it's global warming? ;-) Damn coincidences! IETF 39 was in Munich (August 1997) ArabellaSheraton @ Arabella Park, and it was HOT pretty much the whole week. -Martin
Re: Berlin was awesome, let's come again
On Tue, Aug 6, 2013 at 3:52 PM, Martin Rex m...@sap.com wrote: Ulrich Herberg wrote: I think that the heat was exceptional. I have grown up in Munich, and I have rarely ever seen it that hot (either in Munich or Berlin). Maybe it's global warming? ;-) Damn coincidences! IETF 39 was in Munich (August 1997) ArabellaSheraton @ Arabella Park, and it was HOT pretty much the whole week. Yes -- they said the same thing last time -- no need for ventilation since it never gets too hot here. I noticed the locals on the 200 bus to the beer festival were just as miserable as me. I stopped in a McDonalds for a diet coke, but the ice machine was broken. (I was told it was too hot for it to make ice. Since I was the only American in there, nobody noticed the ice machine didn't work but me ;-) I would still come back -- this was a great city for an IETF -- I just hope for once we get normal weather for July. -Martin Andy
Re: Berlin was awesome, let's come again
--On Wednesday, August 07, 2013 00:52 +0200 Martin Rex m...@sap.com wrote: ... IETF 39 was in Munich (August 1997) ArabellaSheraton @ Arabella Park, and it was HOT pretty much the whole week. If I recall, another very successful meeting in a place we should go back to. Now, if only the IAOC could work out a better weather contract for both Europe and, perhaps, a required March thaw in Minneapolis. john
Re: Berlin was awesome, let's come again
On 08/06/2013 07:36 PM, John C Klensin wrote: ... IETF 39 was in Munich (August 1997) ArabellaSheraton @ Arabella Park, and it was HOT pretty much the whole week. If I recall, another very successful meeting in a place we should go back to. I liked Munich as a destination. But the hotel / meeting facility in Berlin far surpassed the Sheraton in Munich in every way imaginable. Keith
Re: Berlin was awesome, let's come again
On Aug 6, 2013, at 4:48 PM, Keith Moore mo...@network-heretics.com wrote: On 08/06/2013 07:36 PM, John C Klensin wrote: ... IETF 39 was in Munich (August 1997) ArabellaSheraton @ Arabella Park, and it was HOT pretty much the whole week. If I recall, another very successful meeting in a place we should go back to. I liked Munich as a destination. But the hotel / meeting facility in Berlin far surpassed the Sheraton in Munich in every way imaginable. Dear Keith, Agreed. One minor downside was needing an additional flight. It seems AB who handles about a third of the traffic rather than Lufthansa that handles about one fifth, was not the best choice where a 6 hour layover extended an hour on the tarmac in a hot plane. Regards, Douglas Otis
Re: [iaoc-rps] RPS Accessibility
Yes, a group from my lab did this, using short-range RFID. (The range was about 1-2 inches.) It required a bit of a setup which made it hard to replicate at scale, but it worked reasonably well. Privacy concerns are an issue, but you'd have to be very close to the person to sense the card (and you can obviously leave it behind any time you'd want to) - it would be much more convenient to track people using BlueTooth or WiFi MAC addresses, if you'd be so inclined, or just use video cameras. Yes, you can use long-range directional antennas to increase your read range, but those would be rather hard to hide. As was mentioned, the hotel room cards use very much the same technology, and you can't really leave them behind when you leave the building. Henning On Aug 5, 2013, at 5:15 AM, Dan York y...@isoc.org wrote: On the topic of badge-sensing at the mic, I seem to recall that we had this working at an IETF sometime back in the RAI working groups. It was maybe 4 or 5 years ago and I think it may have been some student(s) under Henning Schulzrinne at Columbia... but I am not sure about that. I remember that when you went to the mic you put your badge up to this sensor and your name appeared in the jabber room. We used it in several of the RAI sessions at that IETF. Unfortunately I don't remember how well it worked or why it wasn't continued. There may be someone out there who can provide some insight. (And if it was Henning's students we can just drop him a note.) Dan -- Dan York y...@isoc.org +1-802-735-1624 skype:danyork http://twitter.com/danyork On Aug 2, 2013, at 10:26 AM, Paul Aitken pait...@cisco.com wrote: I've remotely participated in several IETFs. I find that the biggest problem with remote attendance is the lack of visual cues. I've come to realise just how important these are in a meeting. -are people paying attention, are they interested / confused / distracted / bored? Also there's no way for local attendees (in the WG room) to know that remote attendees are at the mic and whose turn it is to speak. There's been some discussion on the 87attendees mailer about badge sensing at the mic - whether QR codes, NFC, or RFID. This could help remote attendees too. eg, see what they did with NFC + mic here: http://www.5thbar.me/blog/2012/09/14/nfc-enabled-badges-at-the-5thbar-mobile-marketing-forum/ P. ___ iaoc-rps mailing list iaoc-...@ietf.org https://www.ietf.org/mailman/listinfo/iaoc-rps
Re: Berlin was awesome, let's come again
Agreed. One minor downside was needing an additional flight. It seems AB who handles about a third of the traffic rather than Lufthansa that handles about one fifth, was not the best choice where a 6 hour layover extended an hour on the tarmac in a hot plane. With any luck, the next time we meet in Germany, they'll have opened the new and much larger Berlin Brandenburg airport which will enable far more direct intercontinental flights.
Re: [iaoc-rps] RPS Accessibility
Ironically, this IETF everyone who stayed at the Intercontinental was walking around with an RFID key in their pocket the whole meeting. How many of us put them in faraday cages? one. i made it a habit I thought the experiment in Hiroshima went well count me in the privacy concerns camp randy
Re: [iaoc-rps] RPS Accessibility
In article m2li4ew2nk.wl%ra...@psg.com you write: Ironically, this IETF everyone who stayed at the Intercontinental was walking around with an RFID key in their pocket the whole meeting. How many of us put them in faraday cages? one. i made it a habit Two. I have a wallet with a built-in tinfoil hat. http://www.idstronghold.com/RFID-Blocking-Secure-Wallet-Bi-Fold-10-Slots/productinfo/IDSH7005/
New Non-WG Mailing List: manet-dlep-rg -- DLEP Radio Group
A new IETF non-working group email list has been created. List address: manet-dlep...@ietf.org Archive: http://www.ietf.org/mail-archive/web/manet-dlep-rg/ To subscribe: https://www.ietf.org/mailman/listinfo/manet-dlep-rg Purpose: This is a closed email list for use by members of the MANET DLEP Radio Design Team. The design team will investigate common metrics that are applicable to a number of RF devices, with the goal being the inclusion of these metrics as standard (or mandatory) metrics for DLEP implementations. Further, the design team will discuss and recommend a strategy for dealing with radio devices capable of committing bandwidth to a specific traffic class (e.g., available bandwidth is allocated based on DSCP traffic markings). For additional information, please contact the list administrators.
New Non-WG Mailing List: doc-dt -- Diameter Overload Control Design Team discussion list
A new IETF non-working group email list has been created. List address: doc...@ietf.org Archive: http://www.ietf.org/mail-archive/web/doc-dt/ To subscribe: https://www.ietf.org/mailman/listinfo/doc-dt Purpose: This list is for Diameter Overload Control design team discussions. For additional information, please contact the list administrators.
