Subject: [hackathon] One Tax API Hackathon proposal

From: Benson Muite <[email-masked]>
Date: Sat, 25 Sep 2021 12:04:53 +0300

Hi,

Have proposed a hackathon topic on One Tax API:
https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon
Many countries are proposing taxes on e-commerce and also labor services 
that are supplied from outside their jurisdictions that have been 
enabled by improvements in internet connectivity.  Complying with these 
requirements can be time consuming and is a trade barrier for trade in 
items and services that do not require regulatory approval.  Having a 
standardized API for reporting and paying these electronically would 
enable compliance at a low cost, especially since automation could be 
used.  Privacy and security considerations are also important in 
creating a standard for such an interface. The aim of this hackathon 
project is to develop a prototype implementation that could become an 
RFC and be adopted as a standard.

Suggestions and contributions are welcome.

Regards,
Benson

---

From: Eliot Lear <[email-masked]>
Date: Sat, 25 Sep 2021 11:18:29 +0200

Hi,

In general I like a low bar for hackathons, but I am not sure that the 
IETF should take this one on.  For one, it's not clear to me that this 
isn't more a matter of data models rather than APIs. We also have no 
experience with handling of this sort of information: this is WAY up the 
stack.

But if you're going to do this, we need to understand what code is going 
to be hacked.  Are the developers from accounting packages going to 
participate?  Can you lay out a bit more of a landscape here?

Eliot

On 25.09.21 11:04, Benson Muite wrote:
> Many countries are proposing taxes on e-commerce and also labor 
> services that are supplied from outside their jurisdictions that have 
> been enabled by improvements in internet connectivity. Complying with 
> these requirements can be time consuming and is a trade barrier for 
> trade in items and services that do not require regulatory approval.  
> Having a standardized API for reporting and paying these 
> electronically would enable compliance at a low cost, especially since 
> automation could be used.  Privacy and security considerations are 
> also important in creating a standard for such an interface. The aim 
> of this hackathon project is to develop a prototype implementation 
> that could become an RFC and be adopted as a standard.
>
> _______________________________________________
> hackathon mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hackathon
> Unsubscribe: mailto:[email-masked]?subject=unsubscribe
>

---

From: Benson Muite <[email-masked]>
Date: Sat, 25 Sep 2021 14:48:37 +0300

Hi,

Thanks for your response. As a relatively open and neutral gathering of 
people with technical expertise, many of whom use and operate parts of 
the internet, this is probably a good setting to produce a technical 
draft that can be operationalized. High level agreements would of course 
be needed, but without some framework produced by people with technical 
expertise, these may take a long time to come into practice. Data models 
are certainly needed.  In many cases, one needs:
i) Relevant tax collection bodies
ii) Identification numbers for the parties involved
iii) Type of good or service and the relevant taxes to be paid, eg. 
sales tax, income tax
iv) Some database lookup on the amount of tax to be paid.

The main problems solve are:
double registration - registering in one jurisdiction should enable you 
to sell in others and comply with regulations the relevant jurisdictions
paperwork reduction -  authorized electronic payments

These would make small and moderate transactions easier to do, which 
regulatory burdens can make unprofitable.  As many payments for such 
services are already done electronically (with relevant methods for 
authentication and collection of payment fees), specifying a method to 
query for the relevant compliance information can build on top of this. 
Traditional financial intermediaries already have identity information 
and comply with local laws.

Tax residency is a complicated issue, see for example 
https://en.wikipedia.org/wiki/Taxation_of_digital_goods
Costs of protecting consumer rights for physical goods, and malware 
prevention for digital goods encourage honesty in digital transactions.

An example of information an enterprise needs to comply with for 
e-commerce in Norway is available at:
https://www.trade.gov/knowledge-product/norway-ecommerce
A benefit of using the internet for commerce is that people in many 
different jurisdictions can reach your website.  Registering to do 
business in every jurisdiction where people can access your website is 
very burdensome.

To limit the scope for a hackathon, would suggest an initial focus on 
sales tax/VAT which usually goes to an official body in the location of 
the consumer or where the consumers payment method is registered.

Benson

---

From: Bob Hinden <[email-masked]>
Date: Sat, 25 Sep 2021 08:19:16 -0700

Eliot,

I had the same reaction to reading this proposal.   It is a problem, but pretty far away from anything IETF does.   We don’t usually develop APIs and I don’t read that this is related to any IETF protocol development.

Bob

> On Sep 25, 2021, at 2:18 AM, Eliot Lear <[email-masked]> wrote:
> 
> Signed PGP part
> Hi,
> 
> In general I like a low bar for hackathons, but I am not sure that the IETF should take this one on.  For one, it's not clear to me that this isn't more a matter of data models rather than APIs. We also have no experience with handling of this sort of information: this is WAY up the stack.
> 
> But if you're going to do this, we need to understand what code is going to be hacked.  Are the developers from accounting packages going to participate?  Can you lay out a bit more of a landscape here?
> 
> Eliot
> 
> 
>> Many countries are proposing taxes on e-commerce and also labor services that are supplied from outside their jurisdictions that have been enabled by improvements in internet connectivity. Complying with these requirements can be time consuming and is a trade barrier for trade in items and services that do not require regulatory approval.  Having a standardized API for reporting and paying these electronically would enable compliance at a low cost, especially since automation could be used.  Privacy and security considerations are also important in creating a standard for such an interface. The aim of this hackathon project is to develop a prototype implementation that could become an RFC and be adopted as a standard.
>>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 25 Sep 2021 09:23:05 -0700

> experience with handling of this sort of information: this is WAY up the

Without taking a position on this proposal, since when do we monitor what
people work on at the hackathon? It's a lot more like a free-for-all than a
BOF and having people work on something at a hackathon certainly isn't any
kind of commitment to take the work on at the IETF.

> participate?  Can you lay out a bit more of a landscape here?

These seem like reasonable questions, but I don't agree with the framing
that we "need" to understand them. If you don't want to participate without
an answer, don't do so, but that shouldn't stop others from doing it.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Sep 2021 18:28:43 +0100

> kind of commitment to take the work on at the IETF.

+1

S

---

From: "Thomas \"Eric\" Brunner-Williams" <[email-masked]>
Date: Sat, 25 Sep 2021 11:42:00 -0700

i think it rational to take a position on this proposal.

not interested. also not in scope. try icann.

-e

---

From: andihavemilestogobeforeisleep <[email-masked]>
Date: Sat, 25 Sep 2021 20:12:23 +0000

i agree.

Sent from ProtonMail for iOS

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Sep 2021 10:43:28 +0200

EKR,

The issue here is more about likelihood of actually accomplishing 
anything.  Do YOU have a codebase that worries about taxes? Do you plan 
to add this sort of code into your base?  I don't and I don't know 
anyone who does.  Do you know of any code base to add this stuff to?  I 
don't and I don't know anyone who does.

If people who DO have such code bases ARE going to show, then the next 
question is whether anyone who participates in the IETF can reasonably 
help them.  This isn't a matter of protocol design.  If not, what does 
the IETF hackathon bring to the table other than... a table (and right 
now we can't even bring that)?

But, Benson, EKR's right:  I can't stand in the way of you doing the 
work here.  I just think it'll be a waste of your time, and possibly 
drive you in the wrong direction.

Eliot

On 25.09.21 18:23, Eric Rescorla wrote:
>
> On Sat, Sep 25, 2021 at 2:19 AM Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
> Without taking a position on this proposal, since when do we monitor 
> what people work on at the hackathon? It's a lot more like a 
> free-for-all than a BOF and having people work on something at a 
> hackathon certainly isn't any kind of commitment to take the work on 
> at the IETF.
>
> These seem like reasonable questions, but I don't agree with the 
> framing that we "need" to understand them. If you don't want to 
> participate without an answer, don't do so, but that shouldn't stop 
> others from doing it.
>
> -Ekr
>
>
>     Eliot
>
>
>     <https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon>
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/hackathon>
>     > Unsubscribe: mailto:[email-masked]
>     <mailto:[email-masked]>?subject=unsubscribe
>     >
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/hackathon>
>     Unsubscribe: mailto:[email-masked]
>     <mailto:[email-masked]>?subject=unsubscribe
>

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 26 Sep 2021 11:40:15 +0200

Since when we cared about this? This is hackathon - an event where people gather, socialize and hack together for fun, not a work camp.

If there’s more people wanting to work on this then great! If not also great, I would gladly welcome Benson to the hackathon nevertheless and hear about his results (or not) at the end.

Ondřej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 26. 9. 2021, at 10:43, Eliot Lear <[email-masked]> wrote:
> 
> The issue here is more about likelihood of actually accomplishing anything.

---

From: Benson Muite <[email-masked]>
Date: Sun, 26 Sep 2021 13:03:23 +0300

Dear Eliot and Eric,

Thanks for your feedback. Just announcing on this list as suggested in 
the Hackathon wiki. Clearly, not everyone on this list will participate 
in every project, but feedback is still appreciated.

One particular use case is taxation of cloud services:

https://itatonline.org/articles_new/a-closer-look-at-taxation-of-cloud-services-internationally/

Some companies which provide services through the cloud and will be 
affected by such taxes and do have employees who participate in IETF. 
They may want to have some say in how they could easily facilitate 
payment of such taxes in many territories without unnecessary 
administrative burden.

KPMG has a set of articles on e-taxes:
https://home.kpmg/us/en/home/insights/2019/06/tnf-digital-economy0.html

A recent example is from Cambodia:
https://home.kpmg/us/en/home/insights/2021/09/tnf-cambodia-vat-ecommerce.html

Within the EU, Peppol ( https://github.com/OpenPEPPOL/ ) is one effort 
to harmonize electronic invoicing, whether this will be adopted 
internationally remains to be seen. The scope is much broader than 
proposed here.

As you indicate, a hackathon should have a clear achievable target. As 
indicated in a previous reply for VAT/Sales tax, one needs:
i) Relevant tax collection bodies
ii) Identification numbers for the parties involved
iii) Type of good or service and the relevant taxes to be paid, eg. 
sales tax, income tax
iv) Some database lookup on the amount of tax to be paid.

The main problems to solve are:
double registration - registering in one jurisdiction should enable you 
to sell in others and comply with regulations the relevant jurisdictions 
for many products and services
paperwork reduction - authorized electronic payments and electronic 
identity confirmation can really help here, for example a certain 
jurisdiction has a paperwork reduction act, the main effect of which is 
to indicate how many hours are needed to fill a form, rather than 
milliseconds of allowed time to respond to an electronic request.

Benson

---

From: "Noah ." <[email-masked]>
Date: Sun, 26 Sep 2021 15:58:50 +0300

Hi Benson

If this will get a green light as a hackathon, I would love to participate
and perhaps bring others on board as I foresee the usefulness of such a
project considering how many African governments are currently coming with
random taxes for all sorts of online use cases.

Noah

---

From: Benson Muite <[email-masked]>
Date: Sun, 26 Sep 2021 16:19:12 +0300

Hi Noah,

Thanks for your interest. Feel free to add yourself as a champion if you 
wish to bring others on board:
https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon
Can then discuss further off list.

Note that the EU also has a One Stop Shop which targets payment 
facilitators to collect VAT:
https://ec.europa.eu/taxation_customs/business/vat/vat-e-commerce/oss_en

Regards,
Benson

On 9/26/21 3:58 PM, Noah . wrote:
> Hi Benson
> 
> If this will get a green light as a hackathon, I would love to 
> participate and perhaps bring others on board as I foresee the 
> usefulness of such a project considering how many African governments 
> are currently coming with random taxes for all sorts of online use cases.
> 
> Noah
> 
> On Sun, 26 Sep 2021, 13:04 Benson Muite, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Dear Eliot and Eric,
> 
>     <https://itatonline.org/articles_new/a-closer-look-at-taxation-of-cloud-services-internationally/>
> 
>     <https://home.kpmg/us/en/home/insights/2019/06/tnf-digital-economy0.html>
> 
>     <https://home.kpmg/us/en/home/insights/2021/09/tnf-cambodia-vat-ecommerce.html>
> 
>     Within the EU, Peppol ( https://github.com/OpenPEPPOL/
>     <https://github.com/OpenPEPPOL/> ) is one effort
>     <mailto:[email-masked]>
>      >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>
>      >>     Hi,
>      >>
>      >>     In general I like a low bar for hackathons, but I am not
>     sure that
>      >>     the
>      >>     IETF should take this one on.  For one, it's not clear to me
>     that
>      >>     this
>      >>     experience with handling of this sort of information: this
>     is WAY
>      >>     up the
>      >>     stack.
>      >>
>      >>
>      >>     But if you're going to do this, we need to understand what
>     code is
>      >>     going
>      >>     > Hi,
>      >>     >
>      >>     > Have proposed a hackathon topic on One Tax API:
>      >>     > https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon
>      >>     <https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon
>     <https://trac.ietf.org/trac/ietf/meeting/wiki/112hackathon>>
>      >>     > Many countries are proposing taxes on e-commerce and also
>     labor
>      >>     > services that are supplied from outside their
>     jurisdictions that
>      >>     have
>      >>     > been enabled by improvements in internet connectivity.
>     Complying
>      >>     with
>      >>     > these requirements can be time consuming and is a trade
>     barrier for
>      >>     > trade in items and services that do not require regulatory
>      >>     approval.
>      >>     > Having a standardized API for reporting and paying these
>      >>     > electronically would enable compliance at a low cost,
>     especially
>      >>     since
>      >>     > automation could be used.  Privacy and security
>     considerations are
>      >>     > also important in creating a standard for such an
>     interface. The
>      >>     aim
>      >>     > of this hackathon project is to develop a prototype
>     implementation
>      >>     > that could become an RFC and be adopted as a standard.
>      >>     >
>      >>     > Suggestions and contributions are welcome.
>      >>     >
>      >>     > Regards,
>      >>     > Benson
>      >>     >
>      >>     > _______________________________________________
>      >>     > hackathon mailing list
>      >>     > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >>     > https://www.ietf.org/mailman/listinfo/hackathon
>      >>     <https://www.ietf.org/mailman/listinfo/hackathon
>     <https://www.ietf.org/mailman/listinfo/hackathon>>
>      >>     > Unsubscribe: mailto:[email-masked]
>     <mailto:[email-masked]>
>      >>     <mailto:[email-masked]
>     <mailto:[email-masked]>>?subject=unsubscribe
>      >>     >
>      >>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >>     <https://www.ietf.org/mailman/listinfo/hackathon
>     <https://www.ietf.org/mailman/listinfo/hackathon>>
>     <mailto:[email-masked]>
>      >>     <mailto:[email-masked]
>     <mailto:[email-masked]>>?subject=unsubscribe
>      >>
>

---

From: Dave Lawrence <[email-masked]>
Date: Sun, 26 Sep 2021 10:35:25 -0400

Ondřej Surý writes:
> Since when we cared about this? This is hackathon - an event where
> people gather, socialize and hack together for fun, not a work
> camp.

I'm not much of a fan of AOLing, but hear, hear!  I appreciate all of
the work Charles and others put into making it happen, but when it
comes down to it the individuals and teams working on any particular
thing are not supervised.

As long as the proponents are aware of what it might or might not mean
in the context of IETF standardization, work on whatever you want.
Welcome, fellow hackers, to our community.

---

From: Andrew Alston <[email-masked]>
Date: Sun, 26 Sep 2021 14:46:06 +0000

While I agree that anyone should be free to work on anything – and I support that fully – I will also say that this type of thing scares me – badly.  Not because of the price of failure – if the hackathon in this regard produces nothing that ever sees the light of day – no harm no foul.

The price of success however – is where I get nervous.  Where does it go from here when we start working on topics like this that are incredibly state specific – on areas where there is very little consensus between countries etc and we succeed?  Do we next see a hackathon for developing API’s to facilitate inter-state shutdowns of social media?  I would hope we would have zero participants in such – but the simple point is – walking down this road opens a door – and it’s a door that I see fraught with real dangers.

Maybe that’s just my paranoia speaking – but as I said – if people wanna work on something – let it be so – but I would hope that this isn’t lending legitimacy to the use of the hackathon to produce what could be some extremely dangerous things.

Andrew

From: hackathon <[email-masked]> on behalf of Dave Lawrence <[email-masked]>
Date: Sunday, 26 September 2021 at 17:36
To: hackathon <[email-masked]>
Subject: Re: [hackathon] One Tax API Hackathon proposal

_______________________________________________
hackathon mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hackathon<https://www.ietf.org/mailman/listinfo/hackathon>
Unsubscribe: mailto:[email-masked]?subject=unsubscribe

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 26 Sep 2021 08:00:02 -0700

Maybe a light criteria for project suitability for an IETF Hackathon would be that it somehow fulfills that part of the IETF mission statement: "Making the Internet work better".

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 26 Sep 2021 11:07:58 -0400

I strongly suspect OASIS is a better forum for this type of work than IETF
or W3C because that is where you are likely to find a consensus of the
relevant expertise.

BUT, you are likely to find that even that isn't quite enough and you need
to go to the UN and WTO because fundamentally, the problem is to get
governments to agree on how they are going to label taxable items and what
forms of tariff they apply. And that is certainly not going to be a closed
set.

Different tariff rates apply according to where the goods are coming from,
where they are going and what the goods are. In some cases there is a
straight tariff, in others there is a value added tax. Tariffs may be
percentages or they may be a fee per item, or both. A global system of
embodied carbon tariffs are in discussion.

There is also a significant faction that is going to resist any effort to
make this work more easily. The complexity of tariffs is in many cases
deliberate as they create non tariff barriers to imports competing with
domestic product.

I can't see how an automated API is going to work unless it has a direct
connection to the organization chartered to manage global trade.

---

From: Benson Muite <[email-masked]>
Date: Sun, 26 Sep 2021 20:45:41 +0300

Dear Phillip,

Thanks for your feedback. OASIS ( https://www.oasis-open.org/ ) may be a 
good second step. Many countries at present are proposing flat taxes on 
digital goods, such as hosted email and cloud compute rental. What will 
the revenue collection agencies adopt to fulfill their missions in these 
cases? Will this be something that is developer friendly, efficient and 
secure? Can we make it easier by developing a prototype?

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 26 Sep 2021 19:54:42 +0200

Again… since when do we police the hackathon topics? The only eligibility was and is to find people who actually want to do the work. We don’t even **require** people to do any work at all, although it’s kind of expected to participate if you come.

Actually, most of the hackathon topics are not even announced on this list, so let’s stop punishing people coming with ideas that might be outside our comfort zone. Because honestly as DNS person I only marginally care or even understand 90% of the work done by the other hackathon groups.

Ondřej

> On 26. 9. 2021, at 17:00, Marc Petit-Huguenin <[email-masked]> wrote:
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 26 Sep 2021 11:36:03 -0700

I was talking about a criteria that one could use to decide if that's the right venue or not for an Hackathon topic, not something that would be enforced.

That's also a good way to choose to participate in someone else's project that does not meet that criteria, for the purpose of sabotaging it.  That's another way to make the Internet work better.

---

From: Sorin Faibish <[email-masked]>
Date: Sun, 26 Sep 2021 14:36:20 -0400 (EDT)

My issue I have is not with the hackathon but with the legitimation of a new IETF protocol as a result of the hackathon.

On 09/26/2021 1:54 PM Ondřej Surý <
[email-masked]> wrote:

Ondřej

--

On 26. 9. 2021, at 17:00, Marc Petit-Huguenin <
[email-masked]> wrote:

Andrew

From: hackathon <
[email-masked]> on behalf of Dave Lawrence <
[email-masked]>

To: hackathon <
[email-masked]>

Ondřej Surý writes:

camp.

hackathon mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/hackathon<
https://www.ietf.org/mailman/listinfo/hackathon>

Unsubscribe: mailto:
[email-masked]?subject=unsubscribe

hackathon mailing list

[email-masked]

Unsubscribe: mailto:
[email-masked]?subject=unsubscribe

--

Marc Petit-Huguenin

Email:
[email-masked]

Blog:
https://marc.petit-huguenin.org

Profile:
https://www.linkedin.com/in/petithug

hackathon mailing list

[email-masked]

Unsubscribe: mailto:
[email-masked]?subject=unsubscribe

hackathon mailing list

[email-masked]

Unsubscribe: mailto:
[email-masked]?subject=unsubscribe

---

From: Botir 4life <[email-masked]>
Date: Sun, 26 Sep 2021 20:42:39 +0200

Hi all,
Can you please delete me from here
Thanks in advance

вс, 26 сент. 2021 г., 20:36 Sorin Faibish <[email-masked]>:

> My issue I have is not with the hackathon but with the legitimation of a
> new IETF protocol as a result of the hackathon.
>
> On 09/26/2021 1:54 PM Ondřej Surý < [email-masked]> wrote:
>
>
> Again… since when do we police the hackathon topics? The only eligibility
> was and is to find people who actually want to do the work. We don’t even
> **require** people to do any work at all, although it’s kind of expected to
> participate if you come.
>
> Actually, most of the hackathon topics are not even announced on this
> list, so let’s stop punishing people coming with ideas that might be
> outside our comfort zone. Because honestly as DNS person I only marginally
> care or even understand 90% of the work done by the other hackathon groups.
>
> Ondřej
> --
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
>
> On 26. 9. 2021, at 17:00, Marc Petit-Huguenin < [email-masked]>
> wrote:
>
> Maybe a light criteria for project suitability for an IETF Hackathon would
> be that it somehow fulfills that part of the IETF mission statement:
> "Making the Internet work better".
>
>
> While I agree that anyone should be free to work on anything – and I
> support that fully – I will also say that this type of thing scares me –
> badly. Not because of the price of failure – if the hackathon in this
> regard produces nothing that ever sees the light of day – no harm no foul.
> The price of success however – is where I get nervous. Where does it go
> from here when we start working on topics like this that are incredibly
> state specific – on areas where there is very little consensus between
> countries etc and we succeed? Do we next see a hackathon for developing
> API’s to facilitate inter-state shutdowns of social media? I would hope we
> would have zero participants in such – but the simple point is – walking
> down this road opens a door – and it’s a door that I see fraught with real
> dangers.
> Maybe that’s just my paranoia speaking – but as I said – if people wanna
> work on something – let it be so – but I would hope that this isn’t lending
> legitimacy to the use of the hackathon to produce what could be some
> extremely dangerous things.
> Andrew
> From: hackathon < [email-masked]> on behalf of Dave Lawrence
> < [email-masked]>
> To: hackathon < [email-masked]>
> Unsubscribe: mailto: [email-masked]?subject=unsubscribe
> Unsubscribe: mailto: [email-masked]?subject=unsubscribe
>
>
>
> --
> Marc Petit-Huguenin
> Unsubscribe: mailto: [email-masked]?subject=unsubscribe
>
>
> Unsubscribe: mailto: [email-masked]?subject=unsubscribe
>

---

From: Melinda Shore <[email-masked]>
Date: Sun, 26 Sep 2021 11:58:36 -0800

> new IETF protocol as a result of the hackathon.

I would guess that the likelihood of that happening approaches zero.
I don't see how it would get through the chartering process, given the
apparent lack of relevance to the IETF and the utter lack of domain
expertise within the body of IETF participants.

That said, I think it's the case that instituting a practice of
policing hackathon topics beyond questions of legality (in which
jurisdiction, though?) and violation of IETF policies around harassment
and whatnot is probably more harmful than someone working on this stuff
in the context of an IETF hackathon.  Given that it's virtual, they
aren't hoovering up valuable workspace in the hackathon venue, they
are almost certainly not taking people away from working on things more
relevant to the IETF, and so on.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 26 Sep 2021 16:04:21 -0400

Well there is this.

Congress Considers A Tax On Email (April Fool's Day Edition) (forbes.com)
<https://www.forbes.com/sites/kellyphillipserb/2015/04/01/with-deficit-not-going-anywhere-congress-considers-a-tax-on-email/?sh=1e42500816d3>

I suspect that at this point you will find that you run into the fact that
just because a government would like to tax something, that does not mean
collection of the tax is feasible.

In general, the IETF has been hostile to taxes and charges for use. The US,
or at least the part of the deep state that is interested, has also been
very much opposed to anything that might constrain communication.

A large number of governments have a monopoly tele communications provider
that has historically provided significant revenues from various telephone
charges. These fees have often been oppressive, $3/min for international
calls. And of course much of those fees have been diverted into the pockets
of corrupt government officials.

Governments have been proposing ways to claw back those fees for the past
25 years and the US and other countries have made sure those proposals go
precisely nowhere but the ITU provides a pretty good forum in which they
can go nowhere.

Sure, in the present Internet design, some functions like SMTP are
sufficiently visible to be able to tax use. But those functions have
increasingly been obscured by cryptography.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 27 Sep 2021 00:03:07 +0000

Thank you Benson for championing a project in the Hackathon and for announcing it on the list. Thanks as well to everyone who has constructively and respectfully provided their input on various aspects of the project.

As others have said, it is intended that projects be related to IETF work and standards. This is intentionally broad and meant to provide guidance and set expectations for those considering leading or joining projects in the Hackathon. Collaboration with people from other organizations (e.g., SDOs, open source communities, etc.) is encouraged.

Ideally and typically, Hackathon projects advance the state of past, current, or future IETF work. If a project brings people together and helps determine there is nothing to do at this time in the IETF, that is not necessarily a bad thing, especially if it results in an improved understanding of the space or helps determine a more appropriate direction for the project.

Cheers,
Charles

On Sep 26, 2021, at 1:04 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

Well there is this.

Congress Considers A Tax On Email (April Fool's Day Edition) (forbes.com)<https://www.forbes.com/sites/kellyphillipserb/2015/04/01/with-deficit-not-going-anywhere-congress-considers-a-tax-on-email/?sh=1e42500816d3>

I suspect that at this point you will find that you run into the fact that just because a government would like to tax something, that does not mean collection of the tax is feasible.

In general, the IETF has been hostile to taxes and charges for use. The US, or at least the part of the deep state that is interested, has also been very much opposed to anything that might constrain communication.

A large number of governments have a monopoly tele communications provider that has historically provided significant revenues from various telephone charges. These fees have often been oppressive, $3/min for international calls. And of course much of those fees have been diverted into the pockets of corrupt government officials.

Governments have been proposing ways to claw back those fees for the past 25 years and the US and other countries have made sure those proposals go precisely nowhere but the ITU provides a pretty good forum in which they can go nowhere.

Sure, in the present Internet design, some functions like SMTP are sufficiently visible to be able to tax use. But those functions have increasingly been obscured by cryptography.

On Sun, Sep 26, 2021 at 1:45 PM Benson Muite <[email-masked]<mailto:[email-masked]>> wrote:
Dear Phillip,

[email-masked]<mailto:[email-masked]>