International Professional Fora:

A study of civil society organisation participation in internet governance

International Professional Fora:

A study of civil society organisation participation in internet governance

In standard setting interoperability is key. It ensures that products developed by different vendors can work together to provide the anticipated service to the user. For the creation of interoperable products, technical experts that participate in standard-setting are required to follow intellectual property rules (IPRs) set within each organisation. Divergences in opinion over IPRs have contributed to patent disputes. In order to prevent potential patent litigation, national and supra-national regulatory and enforcement bodies have urged technical standardisation organisations to outline clear IP rules for participating members (Comino and Manenti 2015; European Commission 2016; FTC, 2016; European Commission 2017). In this project, the focus is on standard setting for the internet within self-regulatory fora which correspond to the four layers of the internet architecture - Network, Internet, Transport and Application – where the IEEE, IETF, W3C and OASIS are the key players. These 4 organisations have recently updated their IPR policies.

The IETF updated its IPR policy in 2017. The IETF’s IPR policy was established in 1992 with the publication of RFC 1310, and later updated in 1996 (RFC 2026), in 2005 (RFC 3979), and, most recently, in May 2017 (RFC 8179) (Contreras and Bradner 2017). The latest revision of the IPR policy updates RFC 2026 and replaces its Section 10 (Intellectual Property Rights), further clarifying certain areas. The RFC 8179 has documented key changes since 2005 in Section 13. A key characteristic of the IETF’s IPR policy is that it requires:

all those contributing to the working group's discussions must disclose the existence of any IPR the Contributor or any    other IETF Participant believes Covers or may ultimately Cover the technology under discussion. This applies to both Contributors and other Participants, and applies whether they contribute in person, via email, or by other means. The requirement applies to all IPR of the Participant, the Participant's employer, sponsor, or others represented by the Participant that are reasonably and personally known to the Participant. No patent search is required. (RFC 8179 2017).

In addition, similarly to other SSOs (see below), the IETF does not make any determinations about the validity and enforceability of the disclosed IPR claims[1]. The major amendments incorporated in the IETF’s new IPR rules have included revisions in terms of Contribution, Participation and Patent disclosure and Failure to disclose. To start with, the definition of Contribution now includes contributing statements that are made within the ‘birds of a feather’ (BOFs)[2], design teams as well as any web sites and chat rooms run by the IETF. In specifying the meaning of the ‘IETF Standards Process’, the IETF has included participants’ activities that are not only directed towards the development of technical standards and specifications, but also towards the production of Informational and Experimental documents. This is something that might, arguably, encourage greater participation of experts other than technical (e.g. policy experts, social science academics, civil society members). The latter is reinforced with the addition of a new definition of ‘Participating in an IETF discussion or activity’ to mean, apart from the numerous ways to making a Contribution listed, ‘any other way acting in order to influence the outcome of a discussion relating to the IETF Standards Process’. It should be noted that the title of the section Contributions in IETF in the older version was changed to Participation in IETF to reflect ‘focus to participation rather than making of Contributions’ (RFC 8179 2017: 43).

In terms of disclosures, the IETF’s new IPR policy draws forward their timing to ‘as soon as reasonably possible after a contribution is submitted or made’, change from contribution published in an Internet-Draft (although the policy allows disclosures to be made later too, if new patents are discovered after the contribution’s publication in an Internet-Draft). A sub-section has been added to acknowledge that Area Directors may become aware of any patent infringement very late in the process (e.g. IETF Last Call or IESG review). An important amendment in terms of ‘blanket disclosures’ has defined that a blanket statement can be accepted only if the discloser shows ‘commitment’ rather than as previously ‘willingness’ to license their patents on a royalty-free basis. In this respect, willingness or commitment to license under FRAND terms does not satisfy the requirements of IETF’s blanket disclosure. Another amendment has introduced ‘General disclosures’ which establishes a public platform (e.g. a web page or a database) to allow any member of the public to post IPR disclosures in line with the IETF’s requirements.  

The IETF’s new IPR rules have also included several new paragraphs to detail considerations for evaluating patent disclosures (See Evaluating Alternative Technologies in IETF Working Groups, A-D). It is important to note that, the IETF does not oblige patent holders to license their patents on a FRAND or another rule, but, in general terms, the organisation prefers to work with technologies with no IPR claims or technologies whose patents are offered on a royalty-free basis (RFC 8179 2017). The IETF also encourages participants with patents to specify their licensing terms in their disclosure forms, mostly choosing not to ‘assert patents against implementations of IETF standards except in defensive situations’ (Contreras and Bradner 2017), meaning ‘If you sue me, I will sue you’. Open source projects have opted for either royalty-free licensing or commitment not to assert IPR rights, based on reciprocity (RFC 8179 2017). Such declarations are now made ‘irrevocable’ and will apply to future implementations even if the IPRs have been transferred to a third party. Disclosures, either oral or written, should be made, if IPRs are concerned, when a ‘contribution’ is made orally. It is important to notice that this is a ‘contribution’ that affects the IETF standardisation process as defined by the rules of RFC 8179, and should not be understood as any oral statement.

In 2015, the IEEE updated its IPR policy after being given a green light from the Antitrust Division of the Justice Department of the United States with a favourable “Business Review Letter” (US Department of Justice 2015). The IEEE rules stipulate that if the organisation receives notice of a patented technology essential for the development of a proposed standard, it has to request the holders of the patent (knows as Standard Essential Patent – SEP) to submit a licensing assurance filling in the IEEE’s Letter of Assurance form (IEEE-SA Patents 2017). The Letter requires the submitter to provide a licensing assurance which can be either 1) a general disclaimer that the SEP owner will not seek to enforce any present of future patent claims to any person or entity implementing the standard within which the patent has been incorporated; or 2) a statement that the patent holder will make the patent available either on a royalty-free bases or royalty rates that are fair, reasonable and non-discriminatory (IEEE-SA Patents 2017). The new policy adds that once this statement is submitted and approved, the terms specified should provide a ‘sufficient compensation for a license to use those Essential Patent Claims and precludes seeking, or seeking to enforce, a Prohibitive Order’ under the conditions of the adopted policy (IEEE-SA Patents 2017). The provision of the assurance, however, cannot be forced; it is a voluntary form of a licensing commitment. The organisation is not too specific on the timing of the submission of the document, but it requires to be completed once the project of the proposed standard is approved[3] and prior to the approval of the finished standard by the IEEE Standards Board. At every working group meeting, participants in the making of the proposed standard are called upon to reveal if they are aware or believe that the process requires the utilisation of a patent that is essential.[4] The IEEE, however, is not responsible for identifying SEPs for which a license may be required, or determining whether the licensing terms specified in the Letter of Assurance (LOA) (if an LOA is not filed, any other form of agreement) are reasonable or non-discriminatory. Nevertheless, one of the key revisions of the IEEE’s IPR policy introduced a clarification of the definition of reasonable rate and a way to calculate it. The IEEE has recommended that the establishment of a reasonable rate should exclude the value resulting from implementing the SEP in the new standard. In addition, this rate should be based on the ‘smallest saleable unit’ (e.g. chipsets) within the products of the implementer who has used the patented technology. The IEEE’s new IPR policy resulted in a split between working group members. While some key companies such as Cisco and Intel insisted that the changes introduced the needed clarifications for licensing under FRAND terms, others Qualcomm, Ericsson, Nokia have refused to submit a Letter of Assurances in line with the new policy (Lloyd 2016).

Companies have argued that the resulting reduction in royalties to SEPs holders might negatively impact innovation and that the policy is therefore ‘commercially reasonable’ (Teece and Sherry 2016; see also Sidak, 2015: 48; Zingales and Kanevskaia 2016). They argue that this may take away SEP holders’ royalties ‘based on a percentage of the final price of any end-product that implements the standard’ (Zingales and Kanevskaia 2016: 223) and leave them only with potential benefits from the ‘volume effect’ of the implementation (Teece and Sherry 2016: 6). However, the change in the IEEE’s policy has been welcomed by the EU, US government and the UK’s BSI (US Department of Justice 2015; European Commission 2017; Lambert and Temple 2015: 23).

During the first five years of its creation, the W3C did not have a formal IPR policy almost, relying on a ‘gentlemen’s agreement’ to utilise patent-free W3C standards (Contreras 2015: 878). Following Intemind’s demand for royalties for the W3C’s P3P standard, the organisation started work on an official IPR policy in 1999. By 2003 the W3C had adopted a royalty-free licensing policy. The most recent update of the organisation’s Patent Policy published in August 2017 included only minor editorial changes aligned with the revision of the W3C Process 2017 (see W3C Patent Policy 2017). Currently, any participant in a W3C working group is obliged to make available SEPs on a royalty-free basis until patent expires. The W3C policy establish an exclusion opportunity for participants in the working groups to exclude any patent claims over the standard they are working on. The duration of the opportunity is offered at certain stages of the W3C’s standardisation process (called Recommendation Track, after the publications of the First Public Working Drafts and the Candidate Recommendations). In addition, the W3C requires participants to disclose any patents when 1) they receive disclosure requests at ‘each new maturity level (Working Draft, Last Call Working Draft, Candidate Recommendation, Proposed Recommendation, Recommendation)’ of the Recommendation track process, and 2) they have actual knowledge of a patent that they believe may be essential for the specification under development. In order to satisfy the disclosure obligation, the patent holder had to commit to make it available under royalty-free terms. Disclosures can be made at any point in time once the Call for Participation has been announced. The W3C acknowledges that ‘Full satisfaction of the disclosure obligation may not be possible until later in the process when the design is more complete. In any case, disclosure as soon as practically possible is required.’ In cases when an identified SEP is not available under on a royalty-free basis, the W3C’s IPR policy provides an opportunity for conflict resolution following the formation of a Patent Advisory Group (PAG). The establishment of PAG was a compromise which, according to Contreras (2015: 879), accommodated the interests of corporations in favour of royalty-bearing licensing.    

The Organisation for the Advancement of Structured Information Standards (OASIS) specialises in the development of (open) software standards. The latest revision of the OASIS’ IPR Policy dates back to June 2012 (see OASIS IPR Policy 2017). Prior to 2005, OASIS’ IPR policy (called Legacy IPR policy) was not fully clarified (Stoll 2014: 15). In 2005, OASIS introduced a new licensing policy according to which each Technical Committee has to specify the ‘IPR mode’ its participants will be required to license any patents that may be essential for the developed standard. Initially, in 2005, those modes were three: licensing under RAND, royalty-free (RF on RAND; RF on Limited Terms). In 2010, the Organisation added another option – the Non-Assertion (NA) mode, whereby the SEP holder was required to declare that they would not sue first[5] any implementer of the standard or specification developed in that technical committee. The latter represents a less cumbersome process than royalty-free licensing, under which fees might not be demanded, but it still requires licensing (Stoll 2014: 8). According to Bekkers and Updegrove (2012: 19), the revisions were needed to allow OASIS’ large portfolio of standardisation activities to pick the licensing terms that best suited their specific effort, as one ‘size’ did not fit all. In effect, it has been argued, the changed moved the Organisation’s licensing regime from a F/RAND to a de facto royalty-free regime which demonstrated an impact on the number and categories of new memberships (Stoll 2014: 3).


[1] Nevertheless, the IETF’s IPR policy acknowledges that participants in working groups will take into account their own views and knowledge of the validity, applicability and enforceability of the disclosed patents when considering the use of specific technology (RFC 8179 2017: 18).  

[2] BOFs represent efforts for starting new standardisation work. Their purpose is to ‘brainstorm’ over new ideas and ascertain interest for a possible working group (see RFC 2418 1998).

[3] This is done through a Project Authorisation Request (PAR) submitted to the IEEE New Standards Committee (NesCom).

[4] The IEEE Patent rules define an Essential Patent Claim as any patent that was necessary for the implementation of a mandatory or optional part of the new standard and that, at the time of the approval of the standard, ‘there was no commercially and technically feasible non-infringing alternative implementation’ (IEEE-SA Patents 2017).

[5] The NA declaration may be suspended or revoked if any other party first sues the SEP holder over an implementation of the developed standard.

 

References

Bekkers, Rudi and Andrew S. Updegrove (2012) ‘A Study of IPR Policies and Practices of a Representative Group of Standards Setting Organizations Worldwide’, SSRN, available at https://ssrn.com/abstract=2333445, last accessed 20/11/2017.

Comino, St. and Fabio M. Manenti (2015) ‘Intellectual Property and Innovation in Information and Communication Technology’, available at: http://publications.jrc.ec.europa.eu/repository/bitstream/JRC97541/jrc97541.pdf, last accessed 20/11/17.

Contreras, Jorge L. (2015). ‘A tale of two layers: Patents, Standardization, and the Internet’, Denver Law Review, 93:4, 855-897.

Contreras, Jorge L. and Scott Bradner (2017). ‘At Long Last, A Revised Patent Policy for IETF: What’s Behind BCP79bis?’, available at https://www.ietf.org/blog/2017/07/whats-behind-bcp79bis/, last accessed 20/11/2017

European Commission (2016) ‘Study on Patent Assertion Entities in Europe’, available at https://ec.europa.eu/digital-single-market/en/news/study-patent-assertion-entities-europe, last accessed 20/11/17.

European Commission (2017) ‘Licensing Terms of Standard Essential Patents’, http://publications.jrc.ec.europa.eu/repository/bitstream/JRC104068/jrc104068%20online.pdf , last accessed 20/11/17.

FTC (2016) ‘Patent Assertion Entity Activity: An FTC. Bureau of Economics Office of Policy Planning Technology Patents & Intellectual Property’, available at https://www.ftc.gov/system/files/documents/reports/patent-assertion-entity-activity-ftc-study/p131203_patent_assertion_entity_activity_an_ftc_study_0.pdf, last accessed 20/11/17.

IEEE-SA Patents (2017) IEEE-SA Standards Board Bylaws, available at http://standards.ieee.org/develop/policies/bylaws/sect6-7.html

Lambert, Ray and Paul Temple (2015) ‘The Relationship between Standards, Standards Development and Intellectual Property’, available at https://www.bsigroup.com/LocalFiles/en-GB/standards/BSI-Standards-and-IP-2015-UK-EN.pdf, last accessed 20/11/17.

Lloyd, Richard (2016) ‘The IEEE’s new patent policy one year on – the battle that’s part of a bigger licensing war’, available at http://www.iam-media.com/Blog/Detail.aspx?g=e8f72d6e-a3f8-45d8-882f-3ebdd3a1d69e, last accessed 20/11/17.

OASIS IPR Policy (2017) ‘Intellectual Property Rights (IPR) Policy’, https://www.oasis-open.org/policies-guidelines/ipr, last accessed 20/11/17.

RFC 2418 (1998) ‘IETF Working Group Guidelines and Procedures’, https://www.ietf.org/rfc/rfc2418.txt, last accessed 20/11/17.

RFC 8179 (2017) ‘Intellectual Property Rights in IETF Technology’, https://tools.ietf.org/html/rfc8179, last accessed 20/11/17.

Sidak, Gregory (2015) ‘The Antitrust Division’s Devaluation of Standard-Essential Patents’, available at https://www.criterioneconomics.com/docs/antitrust-divisions-devaluation-of-standard-essential-patents.pdf, last accessed 20/11/17.

Stoll, Thimo P. (2014) ‘Are You Still in? – The Impact of Licensing Requirements on the Composition of Standards Setting Organizations’, SSRN, available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2535735, last accessed 20/11/17.

Teece, David J. and Edward F. Sherry (2016). ‘The IEEE’s New IPR Policy: Did the IEEE Shoot Itself in the Foot and Harm Innovation?’, available at http://businessinnovation.berkeley.edu/wp-content/uploads/2014/07/14-The-IEEEs-New-Policy_Teece_Sherry_8-3-16_2_Clean.pdf, last accessed 20/11/17.

US Department of Justice (2015) ‘Business Review Letter’, available at https://www.justice.gov/file/338591/download, last accessed 20/11/17.

W3C Patent Policy (2017) ‘W3C Patent Policy’, available at https://www.w3.org/Consortium/Patent-Policy-20170801/, last accessed 20/11/17.

Zingales, Nicolo and Olia Kanevskaia (2016). ‘The IEEE-SA patent policy update under the lens of EU competition law’, European Competition Journal, 12:2-3, 195-235.

In 2013, Google announced that it was working on a way of reducing latency on the web by developing a new transport protocol called QUIC (Quick UDP Internet Connections). As explained here, network performance improves with the decrease of the round trip time (RTT) for establishing connection between the client and the server. The QUIC protocol is intended to outperform the Transmission Control Protocol (TCP) and instead use a new version of the Transport Layer Security (TLS) protocol (TLS 1.3) for encryption over UDP (User Datagram Protocol) which has been relied upon for faster transportation of Internet Protocol (IP) traffic. More clearly, '[t]he standard way to do secure web browsing involves communicating over TCP + TLS, which requires 2 to 3 round trips with a server to establish a secure connection before the browser can request the actual web page. QUIC is designed so that if a client has talked to a given server before, it can start sending data without any round trips, which makes web pages load faster' (Chromium Blog, 17 April 2015). 

The design of QUIC provides for multiplexing the transport of a large number of streams between the server and the client. Google’s QUIC developer, Jim Roskind, explained that the multiplexing function ensured unifying the traffic communication and the reporting and responses to channel characteristics, such as packet losses. QUIC is thus developed to advance the previously designed by Google multiplexing protocol SPDY (pronounced SPeeDY) which became the foundation of HTTP/2 (approved by the IETF in 2015).

In 2015, Google provided an update on the process of testing the QUIC protocol on Google users. It was declared that ‘[r]esults so far are positive, with the data showing that QUIC provides a real performance improvement over TCP thanks to QUIC's lower-latency connection establishment, improved congestion control, and better loss recovery’The greatest gains were announced to come from zero-round-trip connection establishment between endpoints. In terms of video streaming services like YouTube, Google announced that users on QUIC reported 30 % less rebuffs. Recently, however, there were reports suggesting that some of the previous versions of QUIC in Chromium allowed ads to be shielded from ad-blocking applications.

According to Google’s update, already in 2015 ‘roughly half of all requests from Chrome to Google servers [were] served over QUIC’. The company declared its interest to formally propose QUIC to the IETF where a large technical community would be involved in its formal standardisation. A key issue in the standardisation process appears to be the negotiation of the level of encryption vs network management possibilities. One side has argued that ‘QUIC poses a problem for mobile network operators (MNOs)’. The problem seen here is that the ‘modern security measures that are integrated with QUIC are encryption based. And because it is encrypted, MNOs can’t see the traffic that is flowing on their networks.’ MNOs thus fear that this can negatively impact on their monitoring capacities for network management and performance optimisation, including congestion control, trouble shooting. While some QUIC working group members in IETF have not found this necessarily problematic and favoured metadata protection through encryption (see Heise Online), others have raised an issue with the effect of pervasive encryption on operators. Kathleen Moriarty (Dell) and Al Morton (AT&T Labs) have edited an IETF Internet-Draft which tackles the issue of ‘increased use of encryption’ and aims ‘to help guide protocol development in support of manageable, secure networks’. The document shows that, following the pervasive surveillance revelations and the IETF declaration in RFC7258 that ‘pervasive monitoring is an attack’, internet traffic encryption became a key focus. The editors have reminded, however, that RFC7258 has agreed on the need for an increased privacy protection for users; yet, acknowledged that ‘making networks unmanageable to mitigate PM [pervasive monitoring] is not an acceptable outcome’. If the right balance is not reached, the authors have argued, some unfavourable security and network management practices might result. 

 

The Secure Sockets Layer (SSL) standard and its successor - Transport Layer Security (TLS) - have provided security for internet traffic.

The MIKEY-SAKKE (Multimedia Internet KEYing – Sakai Kasahara Key Exchange) protocol was designed by the then known as the Information Security arm of UK’s GCHQ, CESG (now National Cyber Security Centre - NCSC), and published in IETF RFCs 6507, 6508, 6509.

On 7th July 2016, the W3C’s Device and Sensors Working Group returned the specification of the Battery Status API, previously published as a Proposed Recommendation in March 2016, to the status of Candidate Recommendation. The document referred to concerns that have been raised for ‘possible privacy-invasive usage of the Battery Status API’.

On 30 August 2016, the Body of European Regulators for Electronic Communications (BEREC) published its guidelines for the implementation of the EU net neutrality Regulation by the national regulatory agencies (NRAs). The number of responses (481,547 in total) received to the public consultation on the draft guidelines was unprecedented for BEREC; albeit not in comparison to the announced of 3.7 million replies to US FCC’s net neutrality proposals two years ago and the 800,000 emails to the Indian telecoms regulator sent in less than a week, in relation to the same policy issue.

On 29-30 June 2016, the W3C held a workshop on Blockchains and the Web, hosted by the MIT Media Lab. The sponsors of the event included NTT and Blockstream. It was designed to focus on issues on the integration of blockchains into the web and their utilisation.

In relation to broadcasting spectrum, in Europe, the decision-making process in the lead up to the WRC-15 demonstrated the formation of generally three groups of actors – the broadcasters, the mobile cellular players and the wireless broadband industry representatives.

This debate dates back to 2012 when a group of technical experts from Google, Microsoft and Netflix put forward a proposal within the World Wide Web Consortium (W3C) to introduce specifications for Encrypted Media Extensions (EME) in advanced HTML5.

On 29th February 2016, the Internet Engineering Task Force (IETF) published a memo titled IETF Trends and Observations, written by Jari Arkko (Ericsson), Avri Doria (APC), Tobias Gondrom (Huawei), Olaf Kolkman (Internet Society), Steve Olshansky (Internet Society), Benson Schliesser (Brocade Communications), Robert Sparks (Oracle) and Russ White (LinkedIn).

On 5th February 2016 the European Commission (EC) published the results of the public consultation on Standards in the Digital Single Market: setting priorities and ensuring delivery. A total of 156 replies were received from individuals, SMEs, large enterprises and industrial associations, global and regional standardisation organisations and technical standard setting fora, public authorities, research centres. 

Following the decisions made at the ITU’s WRC in November 2015, the European Commission (EC) released its Proposal for a decision on the use of the 470-790 MHz frequency band in the EU.

Preliminary trends are observed in the public consultation on Standards in the Digital Single Market. This consultation relates to developing standards and interoperability in the ICT domain. Stakeholders' views are very important to identify problems and obtain possible future priority-setting policy on ICT standardisation.

Page 1 of 2