Moin!
I haven't been aware of this draft before the FSF encouraged some
people to send there opinion into the IETF mailing list. This isn't my
first post to an IETF mailinglist and I am subscribed to this and
other lists on the IETF, so I do think I qualify as IETF participant.
I did
Hi Cullen,
This is what the forthcoming RFC3588bis will do. Vendor-specific
commands, like the 3GPP ones in this case, would be allocated on a
First Come, First Served basis by IANA. However, for this specific
request, RFC3588bis won't be ready/published soon enough.
Cheers,
Doug Ewell wrote:
I thought Stallman was considered a major religious figure.
Only when he wears that hat
http://uncyclopedia.wikia.com/wiki/St._Ignucius
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Cullen,
The current allocation policy is defined by RFC 3588, section 11.2.1
which indeed makes no distinction between permanent, standard commands
and vendor-specific command codes and requires IETF consensus for all.
This will be fixed by
Hi
Thanks for the comments, I will fix this later on as I get more
comments.
As regards to the minor issue in 4.2.1. I am not sure here, I would say
that it is important to stress that an application must verify that
delivery of reduced-size RTCP is successful. I would personally prefer a
MUST
This campaign continues:
-- Forwarded Message
From: Dave Farber d...@farber.net
Reply-To: Dave Farber d...@farber.net
Date: Wed, 11 Feb 2009 08:20:23 -0500
To: ip i...@v2.listbox.com
Subject: [IP] TODAY: Stop IETF Enactment of Patented Standard for TLS
Begin forwarded message:
From: Seth
Simon Josefsson wrote:
My reading of RedPhone's IPR disclosure 1026 is that they claim to
have a patent application about a larger system that includes
tls-authz as one part, and uses it in particular way. If you want to
build a system matching the numbered list 1..4 in the disclosure
From: Livingood, Jason jason_living...@cable.comcast.com
This campaign continues:
Time to turn of posting by non-subscribers.
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hello
I am writing to add my voice to those calling on the IESG not to
approve this draft.
I am a subscriber to this list and have tried to read and thoughtfully
digest what has been said already before adding my two cents.
It seems clear that, whereas the IPR Disclosure statement asserts that
Dear all:
Two observations on the IPR analysis found below inline. Some text is
highlighted to support my observations.
Eric Rescorla wrote:
SUMMARY
I do not believe this document should be advanced to Proposed Standard
at this time. First, it is not clear that there is really sufficient
Hi,
On 2/11/09 3:21 PM, Bob Jolliffe bobjolli...@gmail.com wrote:
[...]
I think (I hope) their is a general consensus that IETF
standards should be freely implementable and usable for the manner in
which they are intended.
The phrase freely implementable and usable may be the key
I am curious - is this a commitment by the TLS chairs to actually work
on this document? Or simply an attempt to prevent the IESG from
advancing a document that the WG previously declined to work on, and
could easily do so again?
I have no strong feelings on the document itself, as it is out of
Excerpts from Thierry Moreau on Wed, Feb 11, 2009 09:53:42AM -0500:
You seem to assume that patent rights are created by the IPR
disclosure, while they are created by the *patent* (in this case
still at the application stage) that you didn't study.
Actually intellectual property rights are
On 2/11/09 9:47 AM, Powers Chuck-RXCP20 chuck.pow...@motorola.com wrote:
I am curious - is this a commitment by the TLS chairs to actually work
on this document? Or simply an attempt to prevent the IESG from
advancing a document that the WG previously declined to work on, and
could easily do
Scott Brim wrote:
Excerpts from Thierry Moreau on Wed, Feb 11, 2009 09:53:42AM -0500:
You seem to assume that patent rights are created by the IPR
disclosure, while they are created by the *patent* (in this case
still at the application stage) that you didn't study.
Actually
Moin!
On 11.02.2009, at 14:16, Theodore Tso wrote:
No, actually. Point 3 is very tightly constrained to certain types of
Agreements, where Agreements is defined in point 2. Point 4 is about
countersigning authorizations, presumably with the intention of
forwawrding them to a 3rd party. There
Thierry Moreau thierry.mor...@connotech.com writes:
You seem to assume that patent rights are created by the IPR
disclosure, while they are created by the *patent* (in this case still
at the application stage) that you didn't study.
I've seen you claim this a few times, and I wish to attempt
Hi Eric -
I went to review the bidding on the TLS mailing list covering this period and
it appears the archives at
http://www.ietf.org/mail-archive/web/tls/current/maillist.htmlhttp://www.ietf.org/mail-archive/web/tls/current/maillist.html
only go back to the beginning of the year. Could you
Stephan Wenger st...@stewe.org writes:
Hi,
On 2/11/09 3:21 PM, Bob Jolliffe bobjolli...@gmail.com wrote:
[...]
I think (I hope) their is a general consensus that IETF
standards should be freely implementable and usable for the manner in
which they are intended.
The phrase freely
Simon Josefsson wrote:
When evaluating whether to implement a particular technology, you need
to evaluate all the risks. The text of patent (applications) helps in
the evaluation. My point is that the actions of patent holders is
significantly more relevant.
Dear Simon:
Interesting,
Hi Simon,
On 2/11/09 4:43 PM, Simon Josefsson si...@josefsson.org wrote:
Stephan Wenger st...@stewe.org writes:
[...]
The way to address this misalignment is to work in the IETF
towards an FSF-compatible patent regime, and not rant about one specific
draft that somehow got on the FSF's
Hi
2009/2/11 Stephan Wenger st...@stewe.org:
Hi,
On 2/11/09 3:21 PM, Bob Jolliffe bobjolli...@gmail.com wrote:
[...]
I think (I hope) their is a general consensus that IETF
standards should be freely implementable and usable for the manner in
which they are intended.
The phrase freely
Thierry,
Do you have any guidelines / methodology / evaluation criteria / sources
of precedents or any other sources of law? According to those, one
could turn emprircal-observations-of-patent-holder-actions into a) an
evaluation whether to implement and/or b) an evaluation whether to
Hi -
From: Wes Hardaker wjh...@hardakers.net
To: Scott Brim s...@employees.org
Cc: ietf@ietf.org
Sent: Monday, February 09, 2009 10:22 PM
Subject: Re: It's time for some new steps
...
FYI, I unsubscribed twice. The first method (logging in with my
assigned password and hitting
Undergoing a ballot? Is it possible these people believe that
they're stuffing a ballot box?
Shows they do not understand what an IETF last call is about.
On 2/9/09, Rich Schultz r...@tellme.com wrote:
draft-housley-tls-authz-extns-07 is currently undergoing a ballot to become a
proposed
I also was resubscribed. I received the usual totally clarifying
message one has come to expect from Mr Anderson.
None of this suggests to me, however, that we ought to do something.
My understanding (and I'd appreciate being disabused if I'm wrong) is
that Mr Anderson is already not
...
I did spend some time reading the draft, the IPR disclosure and before
stating an opinion it would be nice if the people that have dealt with
it longer could tell me if what I got out of it is correct so far.
1. RedPhone Security applied for some patents that we are talking
about here
Thanks Dan and Jouni,
Seems reasonable. I did not know about 3588bis.
Cullen
On Feb 11, 2009, at 1:53 AM, Romascanu, Dan (Dan) wrote:
Cullen,
The current allocation policy is defined by RFC 3588, section 11.2.1
which indeed makes no distinction between permanent, standard commands
and
ned+i...@mauve.mrochek.com wrote:
I completely disagree with this assessment. The points you mention are quite
specifically talking about Agreements, not certificates.
Yes, this is obviously right, Agreements are not certificates. But I don't
think it's clear that storing Agreements covers
Eric Joe,
In retrospect, I certainly should have consulted with the TLS WG before
initiating yet another Last Call. I failed to do so because the
controversy
had not centered on technical questions, but a great deal of time has
passed, and the mechanism is clearly relevant to the scope of
At 11:37 11-02-2009, Tim Polk wrote:
I will rectify the situation this week and request that the TLS WG
review
the document to gauge interest in this area. I would be delighted to
Are you requesting that the TLS WG review an Internet-Draft that
expired in December 2006?
Regards,
-sm
ned+i...@mauve.mrochek.com wrote:
I completely disagree with this assessment. The points you mention are quite
specifically talking about Agreements, not certificates.
Yes, this is obviously right, Agreements are not certificates. But I don't
think it's clear that storing Agreements
Clint Chaplin clint.chap...@gmail.com writes:
Undergoing a ballot? Is it possible these people believe that
they're stuffing a ballot box?
Shows they do not understand what an IETF last call is about.
The term ballot is used in several places to describe the IESG
decision process, for
On 2009-02-12 08:09, ned+i...@mauve.mrochek.com wrote:
...
P.S. I've read the IPR dlsclosure and the patents claims, but what would
be useful to see is the document shepard writeup. Are those available
somewhere
online? If they are I don't know where to find them and I was unable
to coerce
Dear IETF,
Please do not follow through with the patent-laden TLS authorization
spec. The internet thrives on being open, and requiring us to pay
homage to any one entity (RedPhone Security) to use the internet is
only going to backfire.
Please rethink this. The internet was created in the spirit
Hello all,
as a result of the recent avalanche of messages on the IETF General
Discussion list, I suggest to apply the following two changes to
IETF LC announcements:
(a)
To better qualify the action expected,
replace the clause:
| ... Please send substantive comments to ...
by:
| ...
Hallam-Baker, Phillip wrote:
I think Melinda makes a good point here.
[..]
RMS has a certain number of supporters who are willing to write letters.
That does not mean that RMS's opinion should hold greater weight than
that of other people.
We must assume that each writer is expressing
The proposed standard for TLS-authz includes patent protected elements which
potentially disadvantage certain market participants while leaving no
meaningful alternative.
The IETF should oppose this standard until RedPhone provides a royalty-free
license for all users or otherwise ensures that
Dear Sir/Madam,
I have just heard that a draft IEFT standard, TLS authorisation, which
is apparently patented by a company called RedPhone Security is being
proposed as a standard. If this is true, I wish to register my protest
against such a move. IETF standards have historically been one of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am writing in opposition to the proposed TLS Authorization standard.
RedPhone Security currently holds a patent related to this proposed
standard, and though they are willing to let anyone implement it, they
could still sue anyone who uses it. Until
I am writing to voice my opposition to the IETF standardizing a
patented algorithm (TLS-authz) which has not been offered with
complete royalty-free license to all. As a researcher in the area of
P2P networking, I rely on open-source code to educate my students.
Standards which make open-source
Good folks,
After receiving the briefing email from the FSF, I am moved to send you this
note requesting that the TLS authorization standard not go forward
until/unless RedPhone provide a royalty-free license for all users or
equivalent arrangement.
Sincerely,
Carl Nelson
1321 Vernon
To Whom It May Concern;
I am writing to ask you not to approve the proposed patent-encumbered standard
for TLS authorisation. To do so would fly in the face of the IETF's fundamental
commitment to openness. It would weaken not just the standard itself, but the
IETF's authority in this sphere.
Dear IETF member:
It appears that the following patent-encumbered spec is being considered as
a future Internet standard:
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05617.html
Please reconsider. The Internet has been very successful due largely to its
use of open
Dear IETF committee members,
I believe that IETF supports the advance of the Internet by publishing
free and open standards that everyone can freely use.
Unfortunately, a proposed standard entitled TLS Authorization
Extensions is not free to be used by anyone. The main concern is that
Please Sir, I do not believe that using patented code or components within TLS
Authorization protocols or Standards is at all a good idea, and I strongly
disapprove of the proposal for a standard for TLS by RedPhone that would use
such patents.
I believe that approval of such a standard could
Bonjour,
I am writing to ask you not to approve the proposed
patent-encumbered standard for TLS authorisation. To do so would fly in
the face of the IETF's fundamental commitment to openness. It would
weaken not just the standard itself, but the IETF's authority in this
sphere.
Monique
Please do not approve the proposed patent encumbered standard for TLS
authorization. There must be an alternative. Please push back. Open
standards which can be used by everybody (rich or poor) are extremely
important to the development of and access to the internet ...
This is a PRIVATE
Hi all,
There are still some places in in draft-ietf-pcn-architecture-09 where the
ingress/ingress-node might be misused. Clarification or editorial changes
are required in those places. Please see the detailed comments below.
6.2. Flow termination : In one approach the PCN-egress-node
Internet Engineering Task Force members:
The standard for TLS authorization that was introduced in the IETF for
consideration isn't really a standard but, a restriction because the
technology depends on, or is at least encumbered by, the patent that
Redphone has applied for.
A standard
Internet Engineering Task Force,
Recently, I have been made aware of an IETF proposed standard named
TLS-authz (TLS authorization). If this becomes a standard, a patent
RedPhone Security holds will become an issue for free software users
worldwide. Redphone is gracious enough, now, to offer a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I stand with the many voices protesting:
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
Sirs;
I am writing to protest moving forward with Fourth Last Call:
draft-housley-tls-authz-extns in part because I find the announcement
disingenuous at best. The announcement on the email list quotes IPR 1026:
Since the third Last Call, RedPhone Security filed IETF IPR disclosure
1026. This
As a developer of a network IDS (http://realeyes.sourceforge.net) that
is licensed under the GPL, I am very concerned about the proposed
patent-encumbered standard for TLS authorization. If this becomes a
recommended standard, I am afraid that I would not be able to include
analysis of it in my
The Free Software Foundation and the GNU Project oppose publication
of Transport Layer Security (TLS) Authorization Extensions
(draft-housley-tls-authz-extns) as a proposed standard. We do not
think that RedPhone Security's 1026 disclosure filing provides
sufficient assurance to free software
To whom it may concern:
I'm writing this letter to ask you to not approve proposed
patent-encumbered standard for TLS Authorization. Standards encumbered by
patents, as you should know well, hurt the industrial and technological
progress, as well as the trust put on standards organizations that
Greetings,
Please don't approve any standard, or proposed standard, for TLS!
I am a long-time UNIX systems administrator and recent software
developer, of late at Sendmail, Inc., which implements several
products that make use of TLS -- including the old standby, sendmail
(STARTTLS and
Seth and all,
I agree, the IETF needs to be allot more forceful here. Why they
are not in this instance is difficult for me to understand and goes against
IETF tradition as well.
Seth Johnson wrote:
(Urgent. Send your note TODAY and CONFIRM the automatic reply from
IETF. You can cc
I urge you to be vigilant in ensuring that no patent-encumbered
standards are set.
Standards must be open.
Malcolm McQueen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi.
I have to start with a confession; I'm not a programmer and don't know much
about computers, I just use my computer for school, work and communication
to family and friends. I consider that stuff pretty important, though.
I caught wind that there was a proposal to make some common protocol
Dear IETF
For all the reasons below, and because not even eternal vigilance will
buy us freedom if what is said is said behind closed doors, please do
not approve TLS authorisation as a standard.
Much of the communication on the Internet happens between computers
according to standards that
I am writing to express my strong opposition to the patent-encumbered standard
for TLS authorization. Open, patent-free standards are vital to the continued
health of the software engineering community as a whole. Any successful
attempt to surreptitiously inject patent-encumbered standards
Hello,
I am writing this email to request that the IETF reject the Transport Layer
Security (TLS) Authorization Extensions (draft-housley-tls-authz-extns) as a
proposed standard. The licensing declaration from RedPhone provides caveats
that I believe leave opportunity for future claims against
Please reject this patent encumbered proposed standard. The world has enough
proprietary software.
RedPhone's Licensing Declaration:
The values provided in, and the processing required by the
authorizations (authz_data in the Protocol Document) sent or
received using the techniques defined
I oppose the IETF standard for TLS authorization until RedPhone provides a
royalty-free license for all users. Failing to do so sets a bad precedent
for future IETF standards adoption.
Sincerely,
Scott Mace
Berkeley, California
___
Ietf mailing list
IETF,
I am a web application Performance Engineer for a major SaaS hosting
provider. My customers and I rely on free and open standards to build
web applications that are useful, powerful and openly compatible with
the widest possible range of software. In order for these standards
to remain
Please don't accept the patent-encumbered standard for TLS
authorization. Doing so will allow a single entity to control the use
of the standard and will weaken the authority of the IETF.
--
Tomer
___
Ietf mailing list
Ietf@ietf.org
To whom it may concern,
I hear that you are trying to publish draft-housley-tls-authz-extns as a
proposed standard, despite serious issues regarding a patent by RedPhone
Security:
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05617.html
I urge you *not* to publish this draft
Hello,
I am writing to voice my concern over the new IETF TLS authorization draft,
Transport Layer Security (TLS) Authorization Extensions
draft-housley-tls-authz-extns-07.txt. This draft is encumbered by patents and
thus should not be made an Internet standard. We need to endeavor to keep the
I don't know anything about patents and how they all work -- so I am
probably speaking out of place. Is it possible to just have RedPhone
re-issue the Licensing Declaration with better wording?
Willie
John Sullivan wrote:
The Free Software Foundation and the GNU Project oppose publication
At 3:17 PM +0100 2/11/09, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
| ... Please send substantive comments to ...
by:
| ... Please read this document and send substantive comments to ...
+1
To simplify the resource pointers, and thereby better guide readers
to more information available online
At 12:28 PM -0500 2/11/09, John Sullivan wrote:
The Free Software Foundation and the GNU Project oppose publication
of Transport Layer Security (TLS) Authorization Extensions
(draft-housley-tls-authz-extns) as a proposed standard. We do not
think that RedPhone Security's 1026 disclosure filing
On Wed, 11 Feb 2009, Aaron Williamson wrote:
ned+i...@mauve.mrochek.com wrote:
I completely disagree with this assessment. The points you mention are quite
specifically talking about Agreements, not certificates.
Yes, this is obviously right, Agreements are not certificates. But I don't
On Wed, 11 Feb 2009, Aaron Williamson wrote:
ned+i...@mauve.mrochek.com wrote:
I completely disagree with this assessment. The points you mention are quite
specifically talking about Agreements, not certificates.
Yes, this is obviously right, Agreements are not certificates. But I
There is a serious concern that when individuals are 'filtered out of
IETF lists' whether by official or unofficial means, that their voices
are prevented from being included into the IETF standards process. Are
there any thoughts on how filters in mailing lists should be documented?
Todd
Could I just point out here the real risk that this relevant objection might
get lost in the sea of irrelevant aggitation from the FSF supporters?
From: ietf-boun...@ietf.org on behalf of Eric Rescorla
Sent: Tue 2/10/2009 11:57 PM
To: ietf@ietf.org
Subject:
On Wed, 11 Feb 2009 16:29:05 -0800
Hallam-Baker, Phillip pba...@verisign.com wrote:
Could I just point out here the real risk that this relevant
objection might get lost in the sea of irrelevant aggitation from the
FSF supporters?
I agree. Let's move the substantive discussion to the TLS
TSG == TSG tglas...@earthlink.net writes:
TSG There is a serious concern that when individuals are
TSG 'filtered out of IETF lists' whether by official or
TSG unofficial means, that their voices are prevented from being
TSG included into the IETF standards process.
I'd feel
78 matches
Mail list logo