Dear experts,
The most important essence of network security is fundamental understanding
of randomness. For example, the intensity of cipher system depends upon the
artificial generator of randomness .
There might be no need to say, the strict definition of randomness for human
being
Once again, I wish non-lawyers would ask question before interpreting the
patent law. The experimentation exception referred to in that wikipedia
article [ยง271(e)(1) or Hatch-Waxman exemption] is largely relevant to
pharmaceuticals in process of tests and experiments for regulatory approval.
I wonder that movement of FSF and the related subjects of
patent threats might be a kind of economical hypnotism.
Theorem or formulas of hypnotism might be used.mightn't it?
For me, many local IT companies looks like as slaves of the hypnotism,
congregation of local pseudo doctors,
Apparently, publishing a message as experimental is an invitation by
the IETF to experiment with a new protocol. What sense does that bear,
if accepting IETF invitations is likely to result in legal troubles?
grenville armitage wrote:
Lawrence Rosen wrote:
[..]
Or are some at IETF
As you might know, generally, legal mind tend to focus on past not on
future.
So, law or legal mind can't be used for calculation of states of future.
Law can be described as formulas, I think.
For managing the future, theorem or formulas should be used,
just as academic arts such as social
John Levine wrote:
Apparently, publishing a message as experimental is an invitation
by the IETF to experiment with a new protocol. What sense does that
bear, if accepting IETF invitations is likely to result in legal
troubles?
In North America, at least, experimentation per se doesn't
:14 AM
To: John Levine
Cc: ietf@ietf.org
Subject: Re: Consensus Call for draft-housley-tls-authz
John Levine wrote:
Apparently, publishing a message as experimental is an invitation
by the IETF to experiment with a new protocol. What sense does that
bear, if accepting IETF invitations
Considering the history of the world, traditional law or classic legal mind
can't help managing future. They had been created for hereditary
civilization
based upon papers, pen and ink. It may just pull back legs of evolution
of new civilization.
It can be helped by scientific mind, formulas
On Mon, 9 Mar 2009 14:20:45 -0700, Hallam-Baker, Phillip
pba...@verisign.com said:
Phillip 1) Patents happen, get over it.
The problem is not that patents happen. The
problem is IETF's position when patents happen.
Clearly stated in
On Tue, 10 Mar 2009 12:04:13 -0700, SM s...@resistor.net said:
SM At 11:21 10-03-2009, Richard M Stallman wrote:
RMS In the cases where an experimental RFC is useful, how is it more
RMS useful for the Internet than publication of the same information in
RMS some other way? Long ago,
On Wed, 11 Mar 2009 14:35:36 -0700, Mohsen BANAN
lists-i...@mohsen.banan.1.byname.net said:
Mohsen Now in this particular case of a patent
Mohsen contaminated protocol extension why would non-RFC
Mohsen publication be adequate?
I omitted the important not in that sentence.
I meant:
For the same reason that people publish in conferences and journals --
experimental RFCs are peer-reviewed and accessible via a stable
mechanism.
If experimental RFCs are peer-reviewed, that means they require a kimd
of approval. Others have expplained how this approval has an effect
Actually, in this case, an Experimental RFC is sufficient to assign
a code point. The requirement is 2434 IETF Consensus.
If that is true, an experimental RFC constitutes a very important kind of
approval.
___
Ietf mailing list
Ietf@ietf.org
Not even close. First, you're again totally missing the essential point
here:
That an experimental or informational RFC is NOT a standard. So there is no
equivalency between our doing an experimental RFC and someone else
doing a
standard.
You are the one who compared them, when
What is Vendor A to do to protect itself from such an attack? One
approach is Vendor A patenting the technology and cross-licensing at
reasonable terms (like don't sue us and we won't sue you). What would
you suggest instead?
I have nothing against obtaining patents to be
On 12 mrt 2009, at 21:08, Richard M Stallman wrote:
If experimental RFCs are peer-reviewed, that means they require a kimd
of approval. Others have expplained how this approval has an effect
on the public. I'm saying that the IETF should not give this
approval to patent-restricted practices.
by
refusing to evaluate *disclosed* threats?
/Larry
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Alessandro Vesely
Sent: Wednesday, March 11, 2009 2:28 AM
To: SM
Cc: r...@gnu.org; ietf@ietf.org
Subject: Re: Consensus Call for draft
Lawrence Rosen wrote:
[..]
Or are some at IETF actually trying to set implementers up for legal action by
refusing to evaluate *disclosed* threats?
Helping hapless implementers evaluate patent threats
sounds like a job for the Internet Legal Task Force.
I believe they're two doors
Richard M Stallman rms at gnu dot org wrote:
I have nothing against obtaining patents to be used only defensively.
If company A wants to do this, I presume it will start by give
everyone a royalty-free license to use the original standard.
We can also imagine a troll trap condition of the
I wonder that movement of FSF and the related subjects of
patent threats might be a kind of economical hypnotism.
Theorem or formulas of hypnotism might be used.mightn't it?
// In an essay M in Surely, you are joking Mr.Feynman,
// he said that I've learned how to be under
Stallman
Subject: Re: [Ietf-honest] Consensus Call for draft-housley-tls-authz
At Wed, 11 Mar 2009 02:00:31 -0400 (EDT),
Dean Anderson wrote:
On Fri, 6 Mar 2009, Lawrence Rosen wrote:
Historical Note: They tried the experimental route before. But
Experimental RFC's aren't sufficient for an IANA
On Tue, Mar 10, 2009 at 02:21:09PM -0400, Richard M Stallman wrote:
The W3C has a means that seems to work in practice.
As several people have already pointed out, the analogy with the W3C
is an imperfect one, because whereas anyone can just show up on an
IETF mailing list and thereby be part
Excerpts from Andrew Sullivan on Thu, Mar 12, 2009 11:01:49AM -0400:
On Tue, Mar 10, 2009 at 02:21:09PM -0400, Richard M Stallman wrote:
The W3C has a means that seems to work in practice.
As several people have already pointed out, the analogy with the W3C
is an imperfect one, because
SM wrote:
A request for publication as
Experimental may get rejected if the publication is deemed harmful.
Does that include legal threats?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
At 02:27 11-03-2009, Alessandro Vesely wrote:
Does that include legal threats?
No. Harmful here should be viewed as harmful to the work of a
Working Group or if the document proposes to use free bits for a
purpose which is contrary to the meaning the standard defines.
Regards,
-sm
At Wed, 11 Mar 2009 02:00:31 -0400 (EDT),
Dean Anderson wrote:
On Fri, 6 Mar 2009, Lawrence Rosen wrote:
Historical Note: They tried the experimental route before. But
Experimental RFC's aren't sufficient for an IANA code point.
Actually, in this case, an Experimental RFC is sufficient to
On Mar 11, 2009, at 6:45 AM, SM wrote:
Harmful here should be viewed as harmful to the work of a Working
Group
I think we need to look more at harmful to the Internet.
I note that the IETF has a long established practice of allowing
publication of alternative solutions. I fully support
We really need to get over ourselves here. We may like to think we're the
gatekeepers against standardization of bad stuff, but we're not. There are
simply too many SDOs churning out specifciations these days.
In other words, If we don't do it, someone else will.
Not even close.
Steve Bellovin wrote:
Other than giving up the RFC label for Experimental documents, it's
hard to see what the IETF can do.
Another thing the IETF could do is stop publishing this sort of
document. Anyone that might ask the IETF to publish one can easily
publish it on Internet himself.
frequently does a sensible proposal have to be made to receive a
susbstantive response?
From: ietf-boun...@ietf.org on behalf of Steven M. Bellovin
Sent: Mon 3/9/2009 6:40 PM
To: Stephan Wenger
Cc: SM; r...@gnu.org; ietf@ietf.org
Subject: Re: Consensus Call for draft-housley-tls-authz
@ietf.org
Subject: Re: Consensus Call for draft-housley-tls-authz
Please note that I didn't make a proposal. I can live quite well with a
misalignment of IETF terminology and reality as perceived outside the IETF. So
can the industry, I think. What I was commenting on is that it does not make
As the draft was not approved by the IESG as a Proposed Standard,
the fact is that most people in the IETF community would not consider
it as a proposed standard.
It depends whether one interprets the term according to IETF procedures
or according to everyday understanding of
Stephan Wenger wrote:
Please note that I didn't make a proposal. I can live quite well with a
misalignment of IETF terminology and reality as perceived outside the IETF.
So can the industry, I think. What I was commenting on is that it does not
make sense to me to re-iterate the mantra of
At 10:22 AM -0700 3/10/09, Lawrence Rosen wrote:
If we use different terminology to identify this IETF RFC, how does that
change anything?
Because you earlier complained about IETF standards having known patent issues.
Now we are talking about experimental protocols that are not standards.
On Tue, 10 Mar 2009 14:21:00 -0400
Richard M Stallman r...@gnu.org wrote:
Steve Bellovin wrote:
Other than giving up the RFC label for Experimental documents,
it's hard to see what the IETF can do.
Another thing the IETF could do is stop publishing this sort of
document. Anyone that
At 02:11 10-03-2009, Richard M Stallman wrote:
It depends whether one interprets the term according to IETF procedures
or according to everyday understanding of English.
I agree. That is why I specified IETF community in my reply.
How high is the threshold, in practice, for getting
RFC status without first deciding if the disclosed patent claims are
likely bogus?
/Larry
-Original Message-
From: Paul Hoffman [mailto:paul.hoff...@vpnc.org]
Sent: Tuesday, March 10, 2009 10:31 AM
To: lro...@rosenlaw.com; ietf@ietf.org
Subject: RE: Consensus Call for draft-housley
[mailto:ietf-boun...@ietf.org] On
Behalf Of Lawrence Rosen
Sent: Tuesday, March 10, 2009 3:28 PM
To: 'Paul Hoffman'; ietf@ietf.org
Subject: RE: Consensus Call for draft-housley-tls-authz
Lawrence Rosen wrote:
If we use different terminology to identify this IETF RFC,
how does
that
change
Larry,
On 2009-03-11 08:28, Lawrence Rosen wrote:
...
I don't think we should publish under the IETF imprimatur if there are
*unresolved* known patent issues about which ignorant and cautious people
continue to speculate blindly. Why should any of us waste time and money on
IETF and
At 12:28 PM -0700 3/10/09, Lawrence Rosen wrote:
Lawrence Rosen wrote:
If we use different terminology to identify this IETF RFC, how does that
change anything?
Paul Hoffman replied:
Because you earlier complained about IETF standards having known patent
issues. Now we are talking about
, Phillip [mailto:pba...@verisign.com]
Sent: Tuesday, March 10, 2009 1:24 PM
To: lro...@rosenlaw.com; Paul Hoffman; ietf@ietf.org
Subject: RE: Consensus Call for draft-housley-tls-authz
Institute the policy as you suggest and you have just given the patent
trolls the power to place an indefinite
-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
Behalf Of Lawrence Rosen
Sent: Tuesday, March 10, 2009 3:28 PM
To: 'Paul Hoffman'; ietf@ietf.org
Subject: RE: Consensus Call for draft-housley-tls-authz
Lawrence Rosen wrote:
If we use different terminology to identify
; Paul Hoffman; ietf@ietf.org
Subject: RE: Consensus Call for draft-housley-tls-authz
Institute the policy as you suggest and you have just given the patent
trolls the power to place an indefinite hold on any IETF proposal.
So instead of extorting payment
On 3/10/09 7:46 PM, Lawrence Rosen wrote:
Only occasionally does someone submit a disclosure as misleading and
confusing as the one relating to TLS.
TLS itself (RFCs 2246, 4346, 5246) is not affected by the disclosure at
hand. The impact is limited to a particular extension to TLS (and even
So the answer to your question is that Experimental RFCs are
different from Standards Track ones because, among other things,
there is no implicit IETF recommendation of implementation and
deployment of the technology and because part of the purpose of
publication is
But an experimental RFC is not a Proposed Standard, a proposed
standard, a document that is in the process of being considered
for standardization, or any other sort of standard or
prestandard.
There are people who propose this as a standard; in factual terms,
that makes it a
At 15:12 08-03-2009, Richard M Stallman wrote:
But an experimental RFC is not a Proposed Standard, a proposed
standard, a document that is in the process of being considered
for standardization, or any other sort of standard or
prestandard.
There are people who propose this as a
On Mon, 09 Mar 2009 11:07:10 -0700
SM s...@resistor.net wrote:
As the draft was not approved by the IESG as a Proposed Standard,
the fact is that most people in the IETF community would not consider
it as a proposed standard.
The Experimental designation typically denotes a
At 11:14 09-03-2009, Steven M. Bellovin wrote:
Put another way, an Experimental RFC is no more an IETF standard than a
conference or journal publication. Someone has done something that is
perceived to be of enough interest to the community to publish as an
RFC, but it is manifestly *not* an
.
From: ietf-boun...@ietf.org on behalf of Richard M Stallman
Sent: Sun 3/8/2009 6:12 PM
To: John C Klensin
Cc: jorge.contre...@wilmerhale.com; ietf@ietf.org
Subject: Re: Consensus Call for draft-housley-tls-authz
But an experimental RFC is not a Proposed Standard, a proposed
standard
...@gnu.org; ietf@ietf.org
Subject: Re: Consensus Call for draft-housley-tls-authz
On Mon, 09 Mar 2009 11:07:10 -0700
SM s...@resistor.net wrote:
As the draft was not approved by the IESG as a Proposed Standard,
the fact is that most people in the IETF community would not consider
On 3/9/09 11:14 AM, Steven M. Bellovin s...@cs.columbia.edu wrote:
On Mon, 09 Mar 2009 11:07:10 -0700
SM s...@resistor.net wrote:
As the draft was not approved by the IESG as a Proposed Standard,
the fact is that most people in the IETF community would not consider
it as a proposed
On Mon, 09 Mar 2009 15:35:31 -0700
Stephan Wenger st...@stewe.org wrote:
The IETF might view it this way. Large parts of the
(standardization) world does not. One example in my field of work is
FLUTE, and the surrounding infrastructure of frameworks and FEC
codes. To the best of my
PM
To: Stephan Wenger
Cc: SM; r...@gnu.org; ietf@ietf.org
Subject: Re: Consensus Call for draft-housley-tls-authz
On Mon, 09 Mar 2009 15:35:31 -0700
Stephan Wenger st...@stewe.org wrote:
The IETF might view it this way. Large parts of the
(standardization) world does not. One example in my
--On Friday, March 06, 2009 14:08 -0800 Kurt Zeilenga
kurt.zeile...@isode.com wrote:
...
Okay, so we're being overly anal here. Like we can control
the world of protocol extensions.
Kurt,
While I agree (and strongly so), there is lots of precedent for
the IESG rejecting parameter
While I agree (and strongly so), there is lots of precedent for
the IESG rejecting parameter registrations because of distaste
for a particular extension, presumably in the hope that no
registered value will imply the unpopular extension idea goes
away.
There are indeed lots of
Hi,
On Mar 7, 2009, at 5:38 PM, Christian Huitema wrote:
I agree with Ned. The main purpose of the registry should be to
document what is out there, not to act as a gatekeeper. Even when a
protocol is not a full standard, having a public documentation is
useful. Documentation enables
On Sat, 7 Mar 2009 17:49:54 -1000
David Conrad d...@virtualized.org wrote:
Hi,
On Mar 7, 2009, at 5:38 PM, Christian Huitema wrote:
I agree with Ned. The main purpose of the registry should be to
document what is out there, not to act as a gatekeeper. Even when
a protocol is not a
--On Saturday, March 07, 2009 12:31 -0500 Richard M Stallman
r...@gnu.org wrote:
So the answer to your question is that Experimental RFCs
are different from Standards Track ones because, among
other things, there is no implicit IETF recommendation of
implementation and
Folks,
After some time reflecting on the hundreds of messages submitted to
the IETF discussion list, I have come to several conclusions about
progressing draft-housley-tls-authz. I will summarize the conclusions
up front, then provide the rationale for those decisions in the
remainder
On Mar 6, 2009, at 11:26 AM, Tim Polk wrote:
Folks,
After some time reflecting on the hundreds of messages submitted to
the IETF discussion list, I have come to several conclusions about
progressing draft-housley-tls-authz. I will summarize the
conclusions up front, then provide the
At Fri, 6 Mar 2009 14:26:09 -0500,
Tim Polk wrote:
Folks,
After some time reflecting on the hundreds of messages submitted to
the IETF discussion list, I have come to several conclusions about
progressing draft-housley-tls-authz. I will summarize the conclusions
up front, then
At Fri, 6 Mar 2009 11:34:19 -0800,
Kurt Zeilenga wrote:
I think if the IESG chooses not to publish draft-housley-tls-authz
now, the authors should immediately take it RFC Editor for publication
and the IESG should not object to its timely publication. In this
case, the authors should
On Mar 6, 2009, at 1:59 PM, Eric Rescorla wrote:
At Fri, 6 Mar 2009 11:34:19 -0800,
Kurt Zeilenga wrote:
I think if the IESG chooses not to publish draft-housley-tls-authz
now, the authors should immediately take it RFC Editor for
publication
and the IESG should not object to its timely
At Fri, 6 Mar 2009 13:59:04 -0800,
Kurt Zeilenga wrote:
On Mar 6, 2009, at 1:59 PM, Eric Rescorla wrote:
At Fri, 6 Mar 2009 11:34:19 -0800,
Kurt Zeilenga wrote:
I think if the IESG chooses not to publish draft-housley-tls-authz
now, the authors should immediately take it RFC Editor
That's not what IETF Consensus means in the context of
RFC 2434:
IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are made
via
RFCs approved by the IESG. Typically, the IESG will seek
input on
Kurt == Kurt Zeilenga kurt.zeile...@isode.com writes:
That's not what IETF Consensus means in the context of RFC
2434:
IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are made via
RFCs approved by the
Since Eric pointed out process issues with the independent publication
approach...
While I concur with:
the Last Call comments show rough consensus for publication as an
Experimental RFC.
I do not feel it appropriate to further delay the publication of this
I-D as an Experimental
--On Friday, March 06, 2009 14:58 -0800 Lawrence Rosen
lro...@rosenlaw.com wrote:
...
I do not understand why an Experimental RFC is different in
principle from a standards track RFC when it comes to
patents, since even experimental use of patented technology is
an infringement. However,...
On Mar 6, 2009, at 2:58 PM, Lawrence Rosen wrote:
Tim Polk wrote:
As stated in the Last Call announcement, I had intended to request
IESG evaluation for publication on the standards track. It is clear
that the community does not support publication of this document on
the standards track.
Tim Polk tim.p...@nist.gov writes:
1. Last Call demonstrates that the community does not support
progression of this document on the standards track, but sufficient
support exists for publication as an Experimental RFC.
How can that support be demonstrated? I don't see how we can say
71 matches
Mail list logo
