Re: Last Call: draft-gerhards-syslog-plain-tcp-11.txt (Transmission ofSyslog Messages over TCP) to Informational RFC
I think this a valuable contribution to the work of the IETF and should become an RFC. I wondered if there should be a reference for US-ASCII (such as RFC0020) but on balance I think not; in the context of this I-D, likely different people will be using it to mean different character sets:-( Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Sent: Thursday, November 10, 2011 1:40 AM Subject: Last Call: draft-gerhards-syslog-plain-tcp-11.txt (Transmission ofSyslog Messages over TCP) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Transmission of Syslog Messages over TCP' draft-gerhards-syslog-plain-tcp-11.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. The aim of this specification is to explain how TCP has been used as a transport for syslog messages. The file can be obtained via http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gerhards-syslog-plain-tcp-11.txt (Transmission ofSyslog Messages over TCP) to Informational RFC
That's very interesting. I've produced a number of RFCs over the years that reference US-ASCII and, since I had no idea that RFC 20 existed (it wasn't even on line when I started), I've always used the following reference. No one ever pointed out RFC 20 to me... ANSI, USA Standard Code for Information Interchange, X3.4, American National Standards Institute: New York, 1968. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Dec 13, 2011 at 8:03 AM, t.petch daedu...@btconnect.com wrote: I think this a valuable contribution to the work of the IETF and should become an RFC. I wondered if there should be a reference for US-ASCII (such as RFC0020) but on balance I think not; in the context of this I-D, likely different people will be using it to mean different character sets:-( Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Sent: Thursday, November 10, 2011 1:40 AM Subject: Last Call: draft-gerhards-syslog-plain-tcp-11.txt (Transmission ofSyslog Messages over TCP) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Transmission of Syslog Messages over TCP' draft-gerhards-syslog-plain-tcp-11.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. The aim of this specification is to explain how TCP has been used as a transport for syslog messages. The file can be obtained via http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
11.12.2011 22:05, Julian Reschke wrote: Hi there, Hi Julian, feedback below: 1. Introduction RFC 5988 [RFC5988] defined a way of indicating relationships between resources on the Web. This document specifies a new type of such relationship - 'disclosure' Link Relation Type. It designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation is specified. s/-/- the/? Will fix. Active use of 'disclosure' relation type has been identified. The current version of W3C Publication Rules [W3C-PUBRULES], Bullet 36 of Section 5, defines that each W3C document must have the boilerplate referring to the page where one may find patent disclosures made with regard to such document. As W3C Publication Rules are applied to many documents, that might be under different patent policies, a number of variants of the mentioned boilerplate exist. However, the phrase W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. can be found in each of these variants. Publication Rules specify that, in the source code, it must look like: W3C maintains a a rel=disclosure href=...public list of any patent disclosures/a made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. Maybe it's worth pointing out that this does not apply as verbatim instruction, but as HTML example. I have that - in source code. Maybe I should add in HTML source code? It would be good to confirm with the W3C that this actually is a requirement and not only a suggestion (cc'ing the author of PUBRULES). And I have this as well, as I've introduced this extract with must look like. Such provisions existed in previous versions of Publication Rules as well, so such source text is often found in different W3C documents that predated publication of RFC 5988 significantly. However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. I think the paragraph above is misleading. It was not the point of RFC 5988 to define all current link relations (it *did* add existing HTML4 relations and Atom relations to the new registry but that's a separate thing). This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. I think in both cases the patent disclosure(s) apply to the context, no? Yes. I may change to: Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. to improve readability. This section provides several examples of possible use of 'disclosure' relation type. If the page http://example.org/ipr/meta-spec/ contains a list of patent disclosures made with respect to the specification found at http://example.org/specs/meta-spec/spec.html, the latter would have the following fragment of HTML source code: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html Or, in the case of Link header field, the HTTP response would contain the following header field: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List (Please note that the actual header field will not contain the line break after 'rel' parameter.) It could if the second line was indented; maybe adjust the example? I have: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List both lines are indented with 5 Courier white spaces, and so I think my explanation in parentheses is correct. Appendix A. Acknowledgments Thanks to Bjoern Hoehrmann for noticing that 'disclosure' relation is not properly specified and, correspondingly, initiating this work. The author would also like to acknowledge the contributions of TBD to this document. Who's this TBD guy? :-) You probably :-). Mykyta Yevstifeyev Best regards, Julian ___ Ietf mailing list
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
11.12.2011 22:14, Julian Reschke wrote: On 2011-12-11 21:05, Julian Reschke wrote: Hi there, feedback below: ... Forgot one more thing. The registry already contains the copyright link relation; maybe it would be good to explain who these are different. This is certainly what I should do. Thanks for feedback! Mykyta Yevstifeyev Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
On 2011-12-13 20:07, Mykyta Yevstifeyev (М. Євстіфеєв) wrote: ... Maybe it's worth pointing out that this does not apply as verbatim instruction, but as HTML example. I have that - in source code. Maybe I should add in HTML source code? The latter sounds good. It would be good to confirm with the W3C that this actually is a requirement and not only a suggestion (cc'ing the author of PUBRULES). And I have this as well, as I've introduced this extract with must look like. I'd like to see this confirmed by the W3C. Such provisions existed in previous versions of Publication Rules as well, so such source text is often found in different W3C documents that predated publication of RFC 5988 significantly. However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. I think the paragraph above is misleading. It was not the point of RFC 5988 to define all current link relations (it *did* add existing HTML4 relations and Atom relations to the new registry but that's a separate thing). This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. Well, it doesn't say anything interesting, and might confuse people to think this was an oversight in 5988. Just drop it. 2. 'disclosure' Link Relation Type Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. I think in both cases the patent disclosure(s) apply to the context, no? Yes. I may change to: Whenever the 'disclosure' relation is defined, the target IRI MUST either (1) designate a list of patent disclosures, or (2) refer to a particular patent disclosure made with respect to the material being referenced by context IRI. to improve readability. OK. This section provides several examples of possible use of 'disclosure' relation type. If the page http://example.org/ipr/meta-spec/ contains a list of patent disclosures made with respect to the specification found at http://example.org/specs/meta-spec/spec.html, the latter would have the following fragment of HTML source code: html ... Please visit a rel=disclosure href=http://example.org/ipr/meta-spec/; the IPR page/a for the list of patent disclosures made with respect to this specification. ... /html Or, in the case of Link header field, the HTTP response would contain the following header field: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List (Please note that the actual header field will not contain the line break after 'rel' parameter.) It could if the second line was indented; maybe adjust the example? I have: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List both lines are indented with 5 Courier white spaces, and so I think my explanation in parentheses is correct. Well, HTTP header fields start at column 0 in a message. Of course you can indent your examples, but my point was that if you indent the second line *more*, it would be valid. Like this: Link: http://example.org/ipr/meta-spec/; rel=disclosure; title=Patent Disclosures List ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-disclosure-relation-00.txt (The 'disclosure' Link Relation Type) to Informational RFC
At 11:07 13-12-2011, Mykyta Yevstifeyev wrote: This may be read as if RFC 5988 is to determine all the rel types that were used at the time of its writing, but I don't think the paragraph directly implies this. I mean that it hasn't been registered either centralized (in RFC 5988) or separately here. In the Introduction Section, the following sentence could be dropped: However, 'disclosure' relation type has not been mentioned in RFC 5988 when creating the registry for relation types; nor was it registered separately. The last paragraph of that section explains what the document is about. I suggest an editorial change in Section 2: Whenever the 'disclosure' relation is defined, the target IRI [RFC5998] MUST either Quoting the example in Section 3: The following are the patent disclosures known at present made with respect to this specification: ula rel=disclosure href=http://patent.gov/8546987; U.S. Patent No. 8546987/a/ul ula rel=disclosure href=http://ipr.su/pat/98745-6; U.S.S.R. Patent No. 98745-6/a/ul ula rel=disclosure href=ftp://ftp.legal.va/a/patent3.pdf; Vatical City State Patent No. 3/a/ul If the IETF takes the security of the Vatican City seriously (there's a typo in the example), I suggest adding a .example at the end of the domain names. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2010-06-08 09:14, Julian Reschke wrote: On 07.06.2010 17:11, Werner Donné wrote: Hi, I don't see why Depth:infinity should be ruled out from the start. You can let the server decide if the performance penalty is too high or not. A server with a relational system underneath it, for example, can do this with one query. I don't agree with the bubble up principle. A collection changes when its member set changes. Changing a resource that is referred to by one of the members doesn't affect the collection, whether that resource is a collection or not. I think the bubble up principal is not consistent with the getlastmodified property. It is also not needed if Depth:infinity is supported. Best regards, Werner. Agreed. In particular: defining a report works by defining it for Depth: 0. The semantics for Depth: 1 and Depth: infinity follow by the definition in RFC 3253. It's probably *really* time to pull the definition of REPORT out of RFC 3253 and place it into a separate spec, including more rationale, recommendations for defining new reports, and examples. Best regards, Julian It seems to me that this issue was never addressed. As defined right now, the way REPORT is used doesn't seem to be compatible with the definition of REPORT in RFC 3253, and the definition of the Depth: header field in RFC 4918. Unless I'm missing something, this will be a problem for any implementation that tries to implement the sync report based on a generic WebDAV reporting framework. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-02 00:41, The IESG wrote: ... Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. - Expand acronyms on first use. Typically, the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all member URIs that are currently in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required. I think it would be more consistent with other specs not to send an empty token, but to send *no* token. As an alternative, the client might choose to do its first synchronization using some other mechanism on the collection (e.g. some other form of batch resource information retrieval such as PROPFIND, SEARCH [RFC5323] , or specialized REPORTs such as those defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav]) The CardDAV reference will need to be updated... To implement the behavior for this report a server needs to keep track of changes to any member URIs and their mapped resources in a collection (as defined in Section 3 of [RFC4918]). This includes Actually, RFC 4918 defines member URL; maybe worth adjusting or pointing out it's the same. Marshalling: The request URI MUST identify a collection. The request body MUST be a DAV:sync-collection XML element (see Section 6.1), which MUST contain one DAV:sync-token XML element, and one DAV:prop XML element, and MAY contain a DAV:limit XML element. The request MUST include a Depth header with a value of 1 or infinity. This report definition is in conflict with the definition of the REPORT method in RFC 3253 (http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6). Essentially, a report is applied to just the request URI (depth: 0 or no depth header field), the request URI and it's internal members (1) or all descendants (infinity). A report definition should define the response for the case of Depth: 0. The format for the other cases follows directly from RFC 3253: If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. (Note that I have complained about this a long time ago, http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0041.html). To fix this, the report would need to define Depth: 0 processing on a collection to mean the changes just on that collection (which means membership changes, but not changes to member resources), and the other modes would then follow based on RFC 3253. It doesn't seem to be possible to make this change in a way that doesn't break existing implementations, as RFC 3253 requires the report response format to be well-formed XML (thus only one root element), and that format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. Optimally, this should be fixed. If this can't be fixed I'd argue that the spec should be published as Informational, and that it should include an explanation of the incompatibilty (essentially requiring servers to special-case this report in case they already use a generic WebDAV REPORT framework). The response body for a successful request MUST be a DAV: multistatus XML element, which MUST contain one DAV:sync-token Maybe s/one/a single/ ... Preconditions: (DAV:valid-sync-token): The DAV:sync-token element value MUST be a valid token previously returned by the server. A token can become invalid as the result of being out of date (out of the range of change history maintained by the server), or for other reasons (e.g. collection deleted, then recreated, access control changes, etc...). Does the sync-token need to originate from the same collection? 3.3. Depth behavior Servers MUST support both Depth:1 and Depth:infinity behavior with the DAV:sync-collection report. Clients MUST include either a Depth:1 or Depth:infinity request header with the DAV:sync-collection report. See above; this contradicts the base definition of REPORT. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
[Resending to ietf@ietf.org] I am curious why an IETF WG (SIDR) has endorsed a wholly new protocol through which to configure policy information on routers (as proposed in draft-ietf-sidr-rpki-rtr), particularly when the IETF already has existing standards to do so, namely: NETCONF [RFC4741] YANG [RFC6020]? In addition, given that NETCONF + YANG were designed for extensibility, they would allow operators to take it upon themselves, if they wish, to easily enrich and/or extend RPKI-validated data before it is sent from an RPKI cache to routers, (compared to a binary protocol like RPKI-RTR). I don't see any discussion in draft-ietf-sidr-rpki-rtr as to whether: a) consideration was given to develop a YANG model, for validated RPKI data, which then would use NETCONF to securely transport that from an RPKI cache to the router; and, b) if it was considered, what were the reasons that approach was not pursued. In the short-term, I am concerned that, from an architectural point-of-view, the IETF has not chosen to re-use the existing set of very successful configuration protocols, namely NETCONF YANG, for the task of configuring validated policy information from the RPKI to/within routers. This could not only cause confusion in the industry, but also lead to additional operational costs to operators who would have to maintain two protocols for configuring policy on their network: RPKI-RTR and, separately, NETCONF/YANG, particularly when those same operators already have to use NETCONF/YANG for other router configuration tasks anyway. Furthermore, NETCONF is in shipping deployed implementations today vs. RPKI-RTR which is likely still several years in the future before it starts shipping in GA SW releases, not including the time it will take to qualify it before it sees actual network deployment. Longer term, development of a new configuration protocol, (namely RPKI-RTR), likely has architectural implications given the discussion that occurred at IETF 82 in the SDN informational-gathering session, held on Thursday afternoon. Although it is a too early to tell where the discussions at that SDN meeting will ultimately lead to, there did seem to be a significant amount of interest in the architectural concept of looking at the problem of attempting to configure networks using a top-down methodology and, in particular, re-using those existing IETF protocols, e.g.: NETCONF/YANG, SNMP, etc., southbound from an SDN Orchestrator toward various network elements. As such, it may be useful for the IESG and IAB to collaborate on the long-term architectural implications and additional complexity that another southbound protocol, specifically: RPKI-RTR, could have on future efforts such as those discussed in the SDN meeting. -shane On Nov 29, 2011, at 3:51 PM, The IESG wrote: The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI/Router Protocol' draft-ietf-sidr-rpki-rtr-19.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: [IP] EFF calls for signatures from Internet Engineers against censorship
Begin forwarded message: From: Dave Farber d...@farber.net Subject: [IP] EFF calls for signatures from Internet Engineers against censorship Date: December 14, 2011 4:12:20 GMT+02:00 To: ip i...@listbox.com Reply-To: d...@farber.net -- Forwarded message -- From: Peter Eckersley Date: Tuesday, December 13, 2011 Subject: EFF call for signatures from Internet Engineers against censorship To: David Farber d...@farber.net (For the IP list) Last year, EFF organized an open letter against Internet censorship legislation being considered by the US Senate (https://eff.org/deeplinks/2010/09/open-letter). Along with other activists efforts, we successfully delayed that proposal, but need to update the letter for two bills, SOPA and PIPA, that are close to passing through US Congress now. If you would like to sign, please email me at p...@eff.org, with a one-line summary of what part of the Internet you helped to helped to design, implement, debug or run. We need signatures by 8am GMT on Thursday (midnight Wednesday US Pacific, 3am US Eastern). Also feel free to forward this to colleagues who played a role in designing and building the network. The updated letter's text is below: We, the undersigned, have played various parts in building a network called the Internet. We wrote and debugged the software; we defined the standards and protocols that talk over that network. Many of us invented parts of it. We're just a little proud of the social and economic benefits that our project, the Internet, has brought with it. Last year, many of us wrote to you and your colleagues to warn about the proposed COICA copyright and censorship legislation. Today, we are writing again to reiterate our concerns about the SOPA and PIPA derivatives of last year's bill, that are under consideration in the House and Senate. In many respects, these proposals are worse than the one we were alarmed to read last year. If enacted, either of these bills will create an environment of tremendous fear and uncertainty for technological innovation, and seriously harm the credibility of the United States in its role as a steward of key Internet infrastructure. Regardless of recent amendments to SOPA, both bills will risk fragmenting the Internet's global domain name system (DNS) and have other capricious technical consequences. In exchange for this, such legislation would engender censorship that will simultaneously be circumvented by deliberate infringers while hampering innocent parties' right and ability to communicate and express themselves online. All censorship schemes impact speech beyond the category they were intended to restrict, but these bills are particularly egregious in that regard because they cause entire domains to vanish from the Web, not just infringing pages or files. Worse, an incredible range of useful, law-abiding sites can be blacklisted under these proposals. In fact, it seems that this has already begun to happen under the nascent DHS/ICE seizures program. Censorship of Internet infrastructure will inevitably cause network errors and security problems. This is true in China, Iran and other countries that censor the network today; it will be just as true of American censorship. It is also true regardless of whether censorship is implemented via the DNS, proxies, firewalls, or any other method. Types of network errors and insecurity that we wrestle with today will become more widespread, and will affect sites other than those blacklisted by the American government. The current bills -- SOPA explicitly and PIPA implicitly -- also threaten engineers who build Internet systems or offer services that are not readily and automatically compliant with censorship actions by the U.S. government. When we designed the Internet the first time, our priorities were reliability, robustness and minimizing central points of failure or control. We are alarmed that Congress is so close to mandating censorship-compliance as a design requirement for new Internet innovations. This can only damage the security of the network, and give authoritarian governments more power over what their citizens can read and publish. The US government has regularly claimed that it supports a free and open Internet, both domestically and abroad. We cannot have a free and open Internet unless its naming and routing systems sit above the political concerns and objectives of any one government or industry. To date, the leading role the US has played in this infrastructure has been fairly uncontroversial because America is seen as a trustworthy arbiter and a neutral bastion of free expression. If the US begins to use its central in the network for censorship that advances its political and economic agenda, the consequences will be far-reaching and destructive. Senators, Congressmen, we believe the Internet is too important and too
