RE: IETF 87 Registration Suspended
It strikes me that 'membership fees' as opposed to 'entrance fees' could work around this payment issue. Or incur a different tax... Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Martin Rex [m...@sap.com] Sent: 05 July 2013 02:06 To: Martin J. Dürst Cc: i...@ietf.org; Barry Leiba; IETF discussion list; IAB; Working Group Chairs Subject: Re: IETF 87 Registration Suspended Martin J. Dürst wrote: On 2013/07/04 9:39, Barry Leiba wrote: Registration for IETF87 in Berlin has been suspended to consider the impact of a change in the VAT rules on Registration Fees. We expect registration to open as soon as this matter has been clarified. I don't understand what the effect of VAT rules is on money collected in the U.S. in U.S. Dollars. It's usual in the U.S. that taxes on goods bought and sold are levied as a consumption tax, at the place (i.e. in the state) where the object is bought (and therefore presumably consumed/used). However, that's not a given, and VAT stands for value added tax, and the value addition/consumption can be presumed to happen at the meeting in Berlin (and there's no need for consensus here, it's the opinion of the local tax authority that counts :-(). If the money that is collected is an entrance/participation fee for the venue itself, then the local tax authority might require the local VAT for _all_ visitors, even those that pay in advance or in a different country. While it might be possible to make the necessary tweaks about the fee (maybe not for this meeting, but for future meetings) for the WG sessions themselves, this would be more difficult to argue for the breakfast/buffet/brownies/beverages (I assume that still exists) and the access to the terminal room, where some form of badge checking is usually done in order to protect the resources. -Martin
Re: IETF 87 Registration Suspended
On Fri, 2013-07-05 at 00:11 -0400, Noel Chiappa wrote: From: John Levine jo...@taugh.com what's different in Berlin from Paris and Prague and Maastricht. The Germans have more 'zealous' tax collectors? :-) Noel It appears that the goalposts have been moved - the basic change came in a couple of years ago: http://www.uktrainingworldwide.com/BB/vat-rules-for-events-and-seminars.html but the proximal cause may be to do with an update from last September (and this was instigated in Germany): See page 159 of http://ec.europa.eu/taxation_customs/resources/documents/taxation/vat/key_documents/vat_committee/2012_guidelines-vat-committee-meetings_en.pdf This is probably ultimately down to the tightening of the inter-country trading rules after the clampdown on so-called carousel trading. But with the arcana of VAT rules ... who knows (certainly not me although I have tangled with a few of them)? Doubtless clearing this up will require a confrontation of tax lawyer and VAT officer at dawn in some shady forest glade. /Elwyn
Re: Call for Comment on draft-iab-anycast-arch-implications-09 on Architectural Considerations of IP Anycast
At 11:13 03-07-2013, IAB Chair wrote: This is an announcement of an IETF-wide Call for Comment on Architectural Considerations of IP Anycast (draft-iab-anycast-arch-implications-09). The first version of this draft was submitted in February 2010. The IETF-wide Call is a little more than three years after that. The title of the draft is Architectural Considerations of IP Anycast. The Abstract mentions architectural implications of IP anycast. After reading the draft it seems to me that it is more about considerations of using IP Anycast. In Section 1: As of early 2009, at least 10 of the 13 root name servers were using IP anycast [RSSAC29] ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 62449 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;rssac.org. IN A rssac.org is having DNS issues. The above cites a report published in 2007 about root name servers using IP anycast in 2009. That seems incorrect. In Section 2.1: One of the first documented uses of anycast was in 1994 for a Video Registry experiment [IMR9401]. I suggest using ftp://ftp.rfc-editor.org/in-notes/museum/imr/imr9401.txt as the stable reference for IMR9401. At the same time, site-local-scoped well-known addresses began being used for recursive resolvers [I-D.ietf-ipv6-dns-discovery], but this use was never standardized (see below in Section 3.4 for more discussion). That I-D from 2002 is cited as work in progress. :-) 'Requirements for a Mechanism Identifying a Name Server Instance [RFC4892] cites the use of anycast with DNS as a motivation to identify individual name server instances, and the Name Server ID (NSID) option was defined for this purpose [RFC5001].' From an architectural point of view I would look at it in terms of locator and identifier separation. In Section 3.4: 'Section 3.3 of [RFC4339] proposes a Well-known Anycast Address for recursive DNS service configuration in clients to ease configuration and allow those systems to ship with these well-known addresses configured from the beginning, as, say, factory default. During publication the IESG requested that the following IESG Note be contained in the document:' Section 3 is about principles. RFC 4339 was published in 2006. I didn't look into what seems to be the preferred approach since then. The IESG Note quoted in the draft does not convey much information from an anycast perspective. I guess that Section 3.3.2 of RFC 4339 is more appropriate as it discusses about the disadvantages of using the well-known anycast address. It seems to me that the idea here was more about well-known address instead of anycast. As a comment about history it seems that this goes back to the idea of logical addressing mentioned in 1981. To keep matters easy I would go with the idea of locator of ubiquitous service which offers flexibility to the host. Would it be appropriate to say that one of the assumptions for anycasting an application is that it has a fail-over mode in addition to using a stateless transport? Otherwise the route has to be withdrawn to avoid service outage (see Section 4.5). The draft was an interesting read. I didn't catch the potential for a cascaded failure at first (see Section 4.4). On a second read I realized that I was confusing a specific case with a general approach. The many pitfalls and subtleties mentioned in Section 1 sums up IP anycast. Regards, -sm
RE: IETF 87 Registration Suspended
--On Friday, July 05, 2013 07:40 +0100 l.w...@surrey.ac.uk wrote: It strikes me that 'membership fees' as opposed to 'entrance fees' could work around this payment issue. Or incur a different tax... But the use of a term like membership fee has profound implications for what the IETF claims is our way of doing business. Folks, it is clear that this is both inconvenient and complicated. Would it be possible to just let the IAOC engage in whatever discussions and consultations are needed --i.e., allow them to do their jobs-- without endless amateur [1] speculation on what is going on and what should or could be done about it. Since people are obviously curious and in the interest of openness and transparency, I hope that the IAOC will explain the details and the solutions when they have things under control. But let's let them get them under control first. Just my opinion, of course. john [1] both amateur lawyers and amateur international taxation experts. Anyone who is part of the conversation who is _not_ am amateur should probably volunteer (or market) her or his services offlist to the IAOC or directly to Ray at i...@ietf.org
Re: IETF 87 Registration Suspended
On 5 Jul 2013, at 15:30, John C Klensin j...@jck.com wrote: --On Friday, July 05, 2013 07:40 +0100 l.w...@surrey.ac.uk wrote: It strikes me that 'membership fees' as opposed to 'entrance fees' could work around this payment issue. Or incur a different tax... But the use of a term like membership fee has profound implications for what the IETF claims is our way of doing business. I would add also that many organisations (and funding bodies) would not support claims for membership fees where conference meeting registration fees are perfectly accepted. Tim
Re: IETF 87 Registration Suspended
Understandable. After all, they need to bail out whole countries on a regular basis :) On 7/5/13 1:11 AM, Noel Chiappa wrote: From: John Levine jo...@taugh.com what's different in Berlin from Paris and Prague and Maastricht. The Germans have more 'zealous' tax collectors? :-) Noel
AUTO: Meenakshi Kaushik is on vacation (returning 08/05/2013)
I am out of the office until 08/05/2013. Hello, I am on vacation until Aug 2nd, 2013. For FC/FCoE discussion, issues, RPQ config validation please contact Badri Ramaswamy and/or Min Zhuo. I have uploaded my FC/FCoE presentation slides here .. http://cattail.boulder.ibm.com/cattail/#view=mkaus...@us.ibm.com For QCN and RoCE solutions please contact Keshav Kamble. For Kraken FC please contact Pramodh Mallipatna. For any other topics, please connect with my manager David Iles. Thanks Best, Meenakshi Note: This is an automated response to your message [trill] Last Call: draft-ietf-trill-directory-framework-05.txt (TRILL (Transparent Interconnection of Lots of Links): Edge Directory Assistance Framework) to Informational RFC sent on 07/04/2013 3:45:04 PM. This is the only notification you will receive while this person is away.
AUTO: David M Bond is out of the office (returning 07/08/2013)
I am out of the office until 07/08/2013. I am out of the office until Thursday. If you have an urgent need contact Tom Hu for Security issues and Tamanna Sait for other issues. Note: This is an automated response to your message [trill] Last Call: draft-ietf-trill-directory-framework-05.txt (TRILL (Transparent Interconnection of Lots of Links): Edge Directory Assistance Framework) to Informational RFC sent on 07/04/2013 17:45:04. This is the only notification you will receive while this person is away.
Registration for IETF 87 in Berlin has re-opened
Registration was suspended after discussions with tax specialists and attorneys convinced us that that the rules had changed in the EU and Germany with regard to the impact of the Value Added Tax (VAT) on registration fees. There is an EU requirement to impose the country's Value Added Tax to registration fees where the meeting is held. Accordingly, Germany's 19% VAT has to be collected and paid over to the German tax authorities. The IAOC had to decide whether to change the registration fee to add the tax to it, or whether to keep the fee in place for the meeting and state that the VAT was included in the fee, which action would result in a registration revenue shortfall greater than $100,000 USD. After discussions with the Internet Society the IAOC has decided not to change the total registration fee for IETF87 because of the complexity of dealing with those who have already paid, and those who had budgeted assuming a total fee of $650. ISOC has agreed to cover any resulting yearly budget shortfall resulting from including the VAT in the IETF87 registration fee. We thank the Internet Society for this support. You will notice a change in your final receipt for the meeting, It will include VAT information and a VAT identification number. It is expected that final receipts will become available in the next two weeks. You or your employer may qualify to recover the VAT. We will be providing guidance on this matter in the next two weeks. We and the Internet Society have learned that VAT is a very complex matter and that expertise is required on a going forward basis. To that end the Internet Society is considering proposals to retain a European tax specialist firm to assist us and them in the future. We will be investigating similar issues in other regions. This decision to not change the fee is for this meeting only. The 2014 Budget will take the VAT into consideration when the fees are set for meetings in Europe next year and beyond. We look forward to seeing you in Berlin. Bob Hinden IAOC Chair
Re: Registration for IETF 87 in Berlin has re-opened
Thank you, and ISOC. Well done. Joel On 7/5/2013 11:57 AM, The IAOC wrote: Registration was suspended after discussions with tax specialists and attorneys convinced us that that the rules had changed in the EU and Germany with regard to the impact of the Value Added Tax (VAT) on registration fees. There is an EU requirement to impose the country's Value Added Tax to registration fees where the meeting is held. Accordingly, Germany's 19% VAT has to be collected and paid over to the German tax authorities. The IAOC had to decide whether to change the registration fee to add the tax to it, or whether to keep the fee in place for the meeting and state that the VAT was included in the fee, which action would result in a registration revenue shortfall greater than $100,000 USD. After discussions with the Internet Society the IAOC has decided not to change the total registration fee for IETF87 because of the complexity of dealing with those who have already paid, and those who had budgeted assuming a total fee of $650. ISOC has agreed to cover any resulting yearly budget shortfall resulting from including the VAT in the IETF87 registration fee. We thank the Internet Society for this support. You will notice a change in your final receipt for the meeting, It will include VAT information and a VAT identification number. It is expected that final receipts will become available in the next two weeks. You or your employer may qualify to recover the VAT. We will be providing guidance on this matter in the next two weeks. We and the Internet Society have learned that VAT is a very complex matter and that expertise is required on a going forward basis. To that end the Internet Society is considering proposals to retain a European tax specialist firm to assist us and them in the future. We will be investigating similar issues in other regions. This decision to not change the fee is for this meeting only. The 2014 Budget will take the VAT into consideration when the fees are set for meetings in Europe next year and beyond. We look forward to seeing you in Berlin. Bob Hinden IAOC Chair
IETF 87 Final Agenda
87th IETF Meeting - Berlin, Germany July 28 - August 2, 2013 The final agenda has been posted. https://datatracker.ietf.org/meeting/87/agenda.html https://datatracker.ietf.org/meeting/87/agenda.txt While this is considered the final agenda for printing, changes may be made to the agenda up until and during the meeting. Updates will be reflected on the web version of the agenda. Information about the 87th IETF meeting in Berlin, Germany can be found here: https://www.ietf.org/meeting/87/index.html Thank you and see you in Berlin! Sincerely, The IETF Secretariat
Re: Call for Comment on draft-iab-anycast-arch-implications-09 on Architectural Considerations of IP Anycast
Hi there, I haven't reviewed the draft (but I will). One thing stood out though: On 2013-07-05, at 05:05, SM s...@resistor.net wrote: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 62449 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;rssac.org. IN A rssac.org is having DNS issues. RSSAC.ORG was registered by an individual with an interest in root server operations, but is not (as far as I know) anything to do with RSSAC at this time. Joe
Registration for IETF 87 in Berlin has re-opened
Registration was suspended after discussions with tax specialists and attorneys convinced us that that the rules had changed in the EU and Germany with regard to the impact of the Value Added Tax (VAT) on registration fees. There is an EU requirement to impose the country's Value Added Tax to registration fees where the meeting is held. Accordingly, Germany's 19% VAT has to be collected and paid over to the German tax authorities. The IAOC had to decide whether to change the registration fee to add the tax to it, or whether to keep the fee in place for the meeting and state that the VAT was included in the fee, which action would result in a registration revenue shortfall greater than $100,000 USD. After discussions with the Internet Society the IAOC has decided not to change the total registration fee for IETF87 because of the complexity of dealing with those who have already paid, and those who had budgeted assuming a total fee of $650. ISOC has agreed to cover any resulting yearly budget shortfall resulting from including the VAT in the IETF87 registration fee. We thank the Internet Society for this support. You will notice a change in your final receipt for the meeting, It will include VAT information and a VAT identification number. It is expected that final receipts will become available in the next two weeks. You or your employer may qualify to recover the VAT. We will be providing guidance on this matter in the next two weeks. We and the Internet Society have learned that VAT is a very complex matter and that expertise is required on a going forward basis. To that end the Internet Society is considering proposals to retain a European tax specialist firm to assist us and them in the future. We will be investigating similar issues in other regions. This decision to not change the fee is for this meeting only. The 2014 Budget will take the VAT into consideration when the fees are set for meetings in Europe next year and beyond. We look forward to seeing you in Berlin. Bob Hinden IAOC Chair
IETF 87 Final Agenda
87th IETF Meeting - Berlin, Germany July 28 - August 2, 2013 The final agenda has been posted. https://datatracker.ietf.org/meeting/87/agenda.html https://datatracker.ietf.org/meeting/87/agenda.txt While this is considered the final agenda for printing, changes may be made to the agenda up until and during the meeting. Updates will be reflected on the web version of the agenda. Information about the 87th IETF meeting in Berlin, Germany can be found here: https://www.ietf.org/meeting/87/index.html Thank you and see you in Berlin! Sincerely, The IETF Secretariat
