Brian E Carpenter [EMAIL PROTECTED] wrote:
On 2007-10-26 06:09, Norbert Bollow wrote:
For an extreme example, consider hypothetically the case that an
essential part of the IPv6 protocol stack had such a patent issue.
To be blunter than Ted, this is a problem that the GPL community
has to
I do not believe in a blanket policy, nor am I proposing one.
What I want to do is to establish an effective constraint against Patent
Weasels. A Patent Weasel is not the same as a Patent Troll. A Troll waits till
you have built the bridge and then tells you that he wants a toll.
A Weasel
Hi, Phil,
I'm not seeing anything in your proposal that requires changes to the IPR
procedures in IETF - are you?
I AM seeing something in your proposal that could reasonably be adopted by
specific working groups, and I AM seeing something that might reasonably be
developed into an
I trust the IETF to not endorse any manner of standard that is
encumbered by one or more patents. All standards must be implementable
by whosoever will without the need to license technology. The provision
of nonretractable royalty-free licensing available to whosoever will may
be sufficient to
The Forum Informatikerinnen und Informatiker fuer Frieden und
gesellschaftliche Verantwortung e.V. (FIfF) (Forum Computer Professionals for
Peace and Social Responsibility) opposes publication of
draft-housley-tls-authz-extns as an experimental standard.
We believe that publication of
I'm a software developer who relies on royalty free standards that the IETF has
worked so hard to provide that make the web the success it is. As such I was
troubled by an issue the Free Software Foundation raised about IETF accepting a
patented technology that if used by me in a software
Dear Sirs,
herewith, I would like to ask you to reject TLS authorization as some
kind of standard.
I, as a software developer, cannot implement this standard without
dropping into the
patent trap, having to pay the patent fees or, what is worse, cannot
implement some
kind of free software.
I have a terminological objection to this draft, mainly in section 2. I have
other comments regarding section 2 I'll mention.
First, terminology: the heading for section 2 has ...Table Position..., and
the body refers to code point position in the table. While the term code
table could have
Hello,
as a developer of FOSS and commercial software, I'd like to voice my opinion
against the passing of the TLS-authz-standard as informational.
It's important for us, the devolopers, as well as our customers or users that
the nuts and bolts of our application - internet standards - are
Dear Sir,
As a former manager of the University computing services at the FUNDP
University (Namur, Belgium), and as an individual, I oppose the
publication of draft-housley-tls-authz-extns as an experimental standard.
The patent application disclosed by RedPhone Security has put any free
Dear Madams, dear Sirs,
I want to apply to you not to publicate the draft-housley-tls-authz-extns as an
experimental
standard, because the company RedPhone Security plans to patent this extension.
This would
make it impossible to implement the extension in free software. In my view
standards
Hello,
As a software engineering professional, I have experienced first-hand
the harm done by patents on software.
I ask that you please REJECT any proposed standard (including those
vying merely for experimental or informational status) which is
encumbered by patents. (If the patent is
I am writing to urge the IETF to reject the TLS Authorization
Extensions, unless the Extensions can be implemented fully (including
all Authorizations and access control methods) without royalty or other
encumbrance. Freely implementable IETF standards are vital to the
openness of the internet.
Hello,
I've just read the claim of of RedPhone Security as laid out here:
https://datatracker.ietf.org/ipr/833/
There, they say that they will grant general, royalty-free licenses to
their part, but they also say that they'll retain rights for certain
classes of authorization and access
Dear IETF,
I would like to echo the comments of the FSF in regards to patents in
standards. I believe MPEG is a good example of standards and patents
working horribly together.
Please do not make that same mistake with TLS Authorization.
Thank You,
Bryan Quigley
--
Please avoid sending me Word
Dear Sir or Madam:
Please do not harm free software interests by supporting the experimental
TLS standard. Thank you for your time and consideration.
-Jeff Hankins
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Sirs:
I would like to voice my opposition to approving the TLS-authorization
technology as an experimental standard.
The reason for this opposition is that a company, RedPhone Security, has
applied for a patent on this technology. Approving patented or patent pending
technology as an internet
Joshua Pritikin
2250 Patterson St. #160
Eugene, OR 97405
I have been made aware that the draft-housley-tls-authz-extns proposal
is patent encumbered. If this is the case then I believe it would be
unethical for IETF to endorse this proposal, even as an experimental
standard.
--
Make April 15
Dear Sir or Madam,
I ask the IETF kindly to not include the possible patent-encumbered TLS
Authentification to-be standard into the official paper, neither
official nor through the backdoor of being experimental.
Best Regards
Benjamin Gretsch
___
Hello,
I've only today become aware of a problem where, once again, a company
wants to sneak possibly patent-encumbered stuff into a standard that is
subsequently to be used in software around the world.
As you are most likely already aware of, there is no way for a broad
class of software to
Dear Sir/Madam.
Much of the communication on the Internet happens between computers
according to standards that define common languages. If we are going to
live in a free world using free software, our software must be allowed
to speak these languages.
Unfortunately, discussions about possible
Please do not ratify the TLS authorization standard as experimental or
informational, unless the patent holders agree to a royalty-free license
for all users. Allowing patented standards to be promoted under the IETF
sends a bad message, and creates a two tier system: unencumbered
standards
Hi Pete,
After consulting with my co-authors our view is that industry implemented the
solution as specified in the example, so we need to revise the schema based on
Pete's suggestion to
?xml version=1.0 encoding=utf-8?
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
Hello IETF,
please don't use or publish standards that are not free and with patents
in it !
thank you, ;)
Walter Bender
--
Walter Bender
3. Physikalische Institut
+49-241-8027286
___
Ietf mailing list
Ietf@ietf.org
Please do not allow TLS-authorization to become a standard or even an
experimental one. Standards need to be open, and it isn't.
Alex Bryan
Centennial, Colorado 80015
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
To whom it may concern.
Having been informed that the proposed IETF document TLS Authorisation
contains proprietary technique for which a patent has been filed, I
strongly oppose its registration as IETF document even as an
experimental or informational one.
Such a document, even without
Please consider rejecting the draft mentioned above,
even as an experimental protocol, for the IPR (patent)
reasons that got recently disclosed.
I believe that the objective of this memo is valuable,
and to have such a mechanism available in TLS would be
useful for the community. At the same
I oppose publication of draft-housley-tls-authz-extns as an experimental
standard.
The patent application disclosed by RedPhone Security has put any free software
attempting to implement these extensions in a very difficult position. Free
software developers cannot safely code to the
The Free Software Foundation and the GNU Project oppose publication of
draft-housley-tls-authz-extns as an experimental standard.
The patent application disclosed by RedPhone Security has put any free software
attempting to implement these extensions in a very difficult position. Free
software
Dear IETF,
besides patent nonsense driven by third parties there's more to oppose to.
The currently at IETF discussed TLS-authz is a candidate because
RedPhone Security hinders reaching the basic goal of the IETF: Creating
standards for common languages.
While standardizing a technique like
Dear Sir,
As a network administrator of the University computing services at the
FUNDP University (Namur, Belgium), and as an individual, I oppose
the publication of draft-housley-tls-authz-extns as an experimental
standard.
The patent application disclosed by RedPhone
Hi Roni,
This looks fine to me. The only thing I would say is that I think the
elementFormDefault=qualified is redundant because there is no namespace to
qualify the elements with.
Pete.
P.S. Sorry for the delay in responding to this. I have been away for a few
days.
--
Tom,
You're analysis of the impact on the ECN nonce is accurate. Below is our
reasoning for not including the ECN nonce capability in this proposal...
An ECN nonce capability could be provided within the MPLS EXP field by
using one more of the 8 available codepoints for each DSCP requiring
Because of my strong belief that all standards should be free and that
patent-bound standards are unacceptable, I urge you to reject
draft-housley-tls-authz-extns for any publication whatsoever. Even as an
experimental I think it should be rejected until RedPhone Security will
agree to license its
Hello,
I support and second the comments previously sent to you by the FSF (
http://www.fsf.org/campaigns/software-patents/draft-housley-tls-authz-extns.html).
Please do not let this standardization attempt continue.
--
CRB
Let me introduce you to my very own DMCA-protected encryption key:
BC
To whom it may concern,
Allowing the TLS-authz specification to advance as an experimental or
informational specification is a poor choice by the IETF. The IEFT has
taken a reasonable position on patents and standards in the past. To
compromise this position by creating new form of
Hi -
The existence of IPR claims potentially relevant to the implementation
of a specification has never been sufficient grounds to block the
publication of that specification as an RFC. Given the unfortunate
history of this work, publication of draft-housley-tls-authz-extns
as experimental
On 24 Oct 2007 at 11:01 -0700, Hallam-Baker, Phillip allegedly wrote:
What I would like to do here is to arrive at a set of terms that is
considered to be sufficiently RANDZ
NO license required is better than RANDZ.
___
Ietf mailing list
I oppose publication of draft-housley-tls-authz-extns as an experimental
standard.
The patent application disclosed by RedPhone Security has put any free
software attempting to implement these extensions in a very difficult
position. Free software developers cannot safely code to the
Hello,
The idea of an standard is to make communication possible and easy. A
pattented standard is a call for chaos or a tax on communication. I'm very
much with the FSF in opposing TLS-authz.
Thank you.
--
J. Pablo Fernández [EMAIL PROTECTED] (http://pupeno.com)
To those considering the TLS-authz proposal:
The patent shenanigans of RedPhone Security have reduced
implementation status from open to taxed at the whim of RedPhone
Security. This should be enough to disqualify the proposal from
further consideration unless, and until, RedPhone Security grants
Dears Sirs,
we join the FSF in opposing to the TLS-authz experimental standard!
Kind regards
Reinhard Moosauer
IT Beratung
--
Reinhard Moosauer
IT Beratung
Neustadt 449
84028 Landshut
EMail: [EMAIL PROTECTED]
Tel: (0871) 27 63 92 32
Fax: (0871) 9247871
Web: http://www.m1b.de
Randy Presuhn wrote:
Hi -
The existence of IPR claims potentially relevant to the
implementation of a specification has never been sufficient
grounds to block the publication of that specification as an
RFC. Given the unfortunate history of this work, publication
of
On 10/26/07 2:04 PM, Randy Presuhn [EMAIL PROTECTED] wrote:
Given the unfortunate
history of this work, publication of draft-housley-tls-authz-extns
as experimental seems to be the most sensible path out of this mess.
Hear, hear.
Melinda
___
Ietf
i am not amused !
plz take my vote to act against Software-Patents
best regards
-c-
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Hello,
herewith I express my concerns in pushing TLS-authz as an experimental
or informal standard
(http://tools.ietf.org/wg/tls/draft-housley-tls-authz-extns-07.txt).
The patents hold by Red Phone Security
(https://datatracker.ietf.org/ipr/833/) would prevent developers of open
source software
References: [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL
PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL
PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL
PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL
PROTECTED][EMAIL
I ask you to reject
http://tools.ietf.org/wg/tls/draft-housley-tls-authz-extns-07.txt
from the experimental track, as it was rejected on the official track.
A standard that can only be implemented with permission of and payment
to a software patent holder is no standard at all.
As you know so
On Tue, 23 Oct 2007 10:52:36 +0200
JORDI PALET MARTINEZ [EMAIL PROTECTED] wrote:
As IETF Sergeant-at-arms, I will suggest that this topic is specific to 6MAN
and should be further discussed there.
Books worked for me, but then again, I'm willing to spend my own money
on keeping my knowledge
Best IETF,
In response to the recent TLS submission, I would like to ask you sincerely to
reject at all levels any standard which relies on proprietary or otherwise
commercially-based technologies. Thank you very much for your consideration.
Best regards,
Ismael Fal
[EMAIL PROTECTED]
The IESG is making a call for volunteers for the IETF Administrative
Oversight Committee (IAOC), as described in BCP 101 (RFC 4071), following
the procedures documented in BCP 113 (RFC 4333). The nominations open
now, and they will close on 18 Nov 2007.
In alternate years. the IESG and the IAB
Dear Sirs and Madams,
I just wanted to let you know that I fully agree with the FSF's position
[1] on making TLS-authz an experimental standard. As their rationale is
covering all important points, I can save myself and yourself the effort
to write and read a lengthy rationale of my own.
Best
It is not a major change in principle. But it does have some practical changes.
When we chartered KEYPROV I was told that the IPR regime should not be in the
charter, this was not a concern to me there because all the proposals were OK
IPR wise. But I do want to have the option of the forcing
Is this an official FSF campaign?
My past experience is that RMS begins these campaigns before bothering to find
out what the actual issues are. If RMS wants to influence the debate then he
should join the debate here.
I am not very interested in RMS's opinion on a set of claims he has heard
On 26 Oct 2007 at 11:35 -0700, Hallam-Baker, Phillip allegedly wrote:
Is this an official FSF campaign?
Half of them are CCed to fsf-campaign.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
At 01:13 26-10-2007, Norbert Bollow wrote:
The question is this: Is copyleft open source / free software so
unimportant with regard to any area of internet standards that it
would be justifiable to adopt any specification with fundamentally
incompatible patent situation as a standards-track
Given the current email activity on this issue, I want to echo Randy's support.
We have published encumbered experimental and informational documents
on many occasions. I can see no reason not to do so in this
case. Given that it appears that experimental publication is
sufficient for the
On 2007-10-27 07:04, Randy Presuhn wrote:
Hi -
The existence of IPR claims potentially relevant to the implementation
of a specification has never been sufficient grounds to block the
publication of that specification as an RFC. Given the unfortunate
history of this work, publication of
On Friday 26 October 2007 15:32, Brian E Carpenter wrote:
On 2007-10-27 07:04, Randy Presuhn wrote:
Hi -
The existence of IPR claims potentially relevant to the implementation
of a specification has never been sufficient grounds to block the
publication of that specification as an RFC.
Apparently Megatron put a bunch of messages on hold for eight days,
compare http://article.gmane.org/gmane.ietf.general/27425/raw:
| Original-Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
| by megatron.ietf.org with esmtp (Exim 4.43)
| id 1IlT12-0002lZ-Jq; Fri, 26 Oct 2007
Perhaps the experiement is to see if the purported IPR is enforceable.
From: Scott Kitterman [mailto:[EMAIL PROTECTED]
Sent: Fri 26/10/2007 4:00 PM
To: ietf@ietf.org
Subject: Re: Experimental makes sense for tls-authz
On Friday 26 October 2007 15:32, Brian E
Given the current email activity on this issue, I want to echo Randy's support.
We have published encumbered experimental and informational documents
on many occasions. I can see no reason not to do so in this
case. Given that it appears that experimental publication is
sufficient for the
Hi, Luca,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Thanks,
From: Joel M. Halpern [EMAIL PROTECTED]
We have published encumbered experimental and informational documents
on many occasions. I can see no reason not to do so in this case. Given
that it appears that experimental publication is sufficient for the
registration needs
Brian E Carpenter wrote:
The DOS attack on this list seems to be from people who haven't
read RFC 2026 and use meaningless phrases like experimental
standard.
What was it, 30 messages collected by Megatron over eight days ?
FYI 36 http://tools.ietf.org/html/rfc4949#page-101 offers a
I agree. The DOS attack on this list seems to be from people
who haven't read RFC 2026 and use meaningless phrases like
experimental standard. In fact, publishing this as an experiment
to see if it gets implemented and deployed despite the IPR issue
seems like *exactly* the right thing to do.
On 2007-10-27 11:13, Bernard Aboba wrote:
I agree. The DOS attack on this list seems to be from people
who haven't read RFC 2026 and use meaningless phrases like
experimental standard. In fact, publishing this as an experiment
to see if it gets implemented and deployed despite the IPR issue
Afaik, non-member postings to the list are automatically held in
moderation to trap spam, and moderators are only human.
Brian
On 2007-10-27 08:41, Frank Ellermann wrote:
Apparently Megatron put a bunch of messages on hold for eight days,
compare
On 10/26/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote:
Is this an official FSF campaign?
Yes, http://www.fsf.org/news/oppose-tls-authz-standard.html
Bill
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Brian E Carpenter wrote:
That's quite correct. But when judging the rough consensus of the IETF,
I believe that the IESG is fully entitled to consider whether multiple
similar messages from people who have rarely if ever participated in
IETF activities carry as much weight as messages from
(Cross posting removed)
On 2007-10-24 22:56, Philippe Verdy wrote:
...
However, the FSF recognizes that, until now, the IETF was more strict about
the licensing conditions, rejecting proposals that included royalties-maker
licenses and explicit personal agreement between the licensor and the
Actually, yes, we do leave the IESG to make the judgement, subject
to appeal to the IAB. I also think it's reasonably clear that the
IESG is allowed to recognize that circumstances alter cases rather
than to automatically follow precedents. But that's certainly a
matter of interpretation.
The likes of implementers (of protocols), whether in the open-source community
or as an employee of a vendor of hardware or software, should be given as
much, if not more, consideration.
Ditto folks who are involved in designing/building host operating systems or
equivalent embedded
To dispel any possible doubt, I agree violently
with what Brian D says below.
Brian C
On 2007-10-27 13:20, Brian Dickson wrote:
Brian E Carpenter wrote:
That's quite correct. But when judging the rough consensus of the IETF,
I believe that the IESG is fully entitled to consider whether
You are reminded of MARID?
That was the last time RMS had one of these write in campaigns. That then led
to a counter-write-in campaigns.
Lets all write Congress while we are at it.
-Original Message-
From: Frank Ellermann [mailto:[EMAIL PROTECTED]
Sent: Friday, October 26, 2007
Brian E Carpenter skrev:
Afaik, non-member postings to the list are automatically held in
moderation to trap spam, and moderators are only human.
And I do think that one reason why letter-writing campaigns against the
IETF have been rare is that it's hard to argue that people who care
[EMAIL PROTECTED] (Noel Chiappa) writes:
I concur [with ignoring requests to reject
'draft-housley-tls-authz-extns' on grounds of patent encumbrance] -
and I think this is the action we should take, no matter how many
emails we see from people we've never heard from before (and
probably
Joel M. Halpern [EMAIL PROTECTED] writes:
We have published encumbered experimental and informational
documents on many occasions. I can see no reason not to do so in
this case.
The reasons are the same as they have always been. Making a mistake in
the past is no reason to continue making
The IESG has received a request from the Layer 2 Virtual Private
Networks WG (l2vpn) to consider the following document:
- 'Requirements for Multicast Support in Virtual Private LAN Services '
draft-ietf-l2vpn-vpls-mcast-reqts-05.txt as an Informational RFC
The IESG plans to make a decision
The IESG has received a request from the Layer 2 Virtual Private
Networks WG (l2vpn) to consider the following document:
- 'L2VPN OAM Requirements and Framework '
draft-ietf-l2vpn-oam-req-frmk-09.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from an individual submitter to consider
the following document:
- 'IPv4 Address Conflict Detection '
draft-cheshire-ipv4-acd-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
The IESG has received a request from the Site Multihoming by IPv6
Intermediation WG (shim6) to consider the following document:
- 'Failure Detection and Locator Pair Exploration Protocol for IPv6
Multihoming '
draft-ietf-shim6-failure-detection-09.txt as a Proposed Standard
The IESG
The IESG has received a request from the Layer 2 Virtual Private
Networks WG (l2vpn) to consider the following document:
- 'VPLS Interoperability with CE Bridges '
draft-ietf-l2vpn-vpls-bridge-interop-02.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Definitions for Textual Conventions and for Managing Pseudowires
over PSN '
draft-ietf-pwe3-pw-tc-mib-12.txt as a Proposed Standard
The IESG plans to make a
The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Pseudowire (PW) Management Information Base '
draft-ietf-pwe3-pw-mib-12.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
85 matches
Mail list logo
