I have no problem with additional access via HTTPS, IETF already have it.
It is better to have more ways to deliver content. The interested party has
the freedom to choose the best way to access, HTTPS, HTTP, FTP, anything.
If the issue is privacy for those who access, HTTPS can help partially,
they do not intercept the documents that the person reads, but still be
able to know that there was a connection to the computer with the IP
address of the IETF.
But if the problem is to ensure the integrity of documents (RFCs) I suggest
that the RFC Editor digitally sign each published RFC (using GPG), thus
making it possible to check if the document has not been altered during
communication or storage.
Sincerely,
__
Thiago Marinello
+55 19 9248 0860
On Wed, Nov 6, 2013 at 9:39 AM, Dave Cridland <dave(_at_)cridland(_dot_)net>
wrote:
On Wed, Nov 6, 2013 at 11:28 AM, Eric Burger
<eburger(_at_)standardstrack(_dot_)com>wrote:
How does the use of HTTPS restrict who can participate in the IETF? That
is like saying that because we no longer offer Gopher, we have closed off
participation to some (possibly null) set of Internet users.
If we do not encourage the use of our own work, why should anyone else
use it?
Requiring HTTPS, particularly with reasonable cipher suites, might
restrict use of from certain jurisdictions.
Allowing HTTPS, on the other hand, does not. Unfortunately, because of the
nature of HTTP/HTTPS, we cannot perform opportunistic encryption in the
same way as with the mail and XMPP services we use.
On Nov 5, 2013, at 10:41 PM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com
wrote:
This is, or is supposed to be, an open standards body, one that is
trying to encourage as many qualified people as possible to participate.
It makes no sense at all to restrict access in this way.