Spencer Dawkins wrote:
Document: draft-ietf-avt-rtp-vorbis-06
Reviewer: Spencer Dawkins
Review Date: 26 Oct 2007 (sorry, late!)
IETF LC End Date: 22 Oct 2007
IESG Telechat date:
Summary: This document is close to ready for publication as a Proposed
Standard. I have a small number of
[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
Some important things that the FSF folks seem NOT to understand,
and frankly seem to aggressively NOT want to understand, are:
- Many RFCs are *not* on the IETF standards track.
- Any Experimental RFC is *not* on the IETF standards track.
So there is no endorsement by IETF in publishing
To whom it may concern,
I have been made aware that the technology described in the
'draft-housley-tls-authz-extns' proposal is encumbered by patents held
by entities with a history of patent enforcement.
All software developers, regardless of whether they produce free
software or proprietary,
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
RJ Atkinson wrote:
Some important things that the FSF folks seem NOT to understand,
and frankly seem to aggressively NOT want to understand, are:
- Many RFCs are *not* on the IETF standards track.
- Any Experimental RFC is *not* on the IETF standards track.
So there is no endorsement
- Many RFCs are *not* on the IETF standards track.
One of the commenters mentioned that even Informational RFCs are seen,
by the uninitiated, as having the force of a standard.
- Any Experimental RFC is *not* on the IETF standards track.
So there is no endorsement by IETF in publishing
RJ == RJ Atkinson [EMAIL PROTECTED] writes:
RJ I support the idea that virtually any document ought to be
RJ able to be published as an Informational RFC or Experimental
RJ RFC. Technology that is useful will be adopted if
RJ economically sensible, whether in an RFC or not,
Ben == Ben Finney [EMAIL PROTECTED] writes:
Ben To whom it may concern, I have been made aware that the
Ben technology described in the 'draft-housley-tls-authz-extns'
Ben proposal is encumbered by patents held by entities with a
Ben history of patent enforcement.
I'd appreciate
it is interesting that the free software foundation is espousing
censorship
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
On Mon, Oct 29, 2007 at 09:55:06AM -0400,
Scott O. Bradner [EMAIL PROTECTED] wrote
a message of 9 lines which said:
it is interesting that the free software foundation is espousing
censorship
It is absolutely ridiculous to call censorship a call to NOT publish
in *our* RFC series a
I seem to have hit a nerve
you are asking the IETF to not publish an IETF doucment - what else
can you call it?
Scott
---
On Mon, Oct 29, 2007 at 09:55:06AM -0400,
Scott O. Bradner [EMAIL PROTECTED] wrote
a message of 9 lines which said:
it is interesting that the free software
From: Ben Finney [EMAIL PROTECTED]
.. idea patents place control over *every* independent implementation of
an idea in the hands of *one* entity, who then gets to dictate whatever
terms they like. This is unjust ... Even developers who are not
intending to use ideas
On Mon, Oct 29, 2007 at 10:20:23AM -0400,
Scott O. Bradner [EMAIL PROTECTED] wrote
a message of 31 lines which said:
you are asking the IETF to not publish an IETF doucment - what else
can you call it?
So, each time in a Last Call, someone says This document should not
be published, it is
Did you consider that the IANA allocation policy for the two IANA values
required by the document is IETF Consensus?
The standards track status of the document doesn't matter then. What
matters is if the registration meets IETF Consensus, and the IESG
decides this.
I think the policies around
As a personal political view, I happen to be opposed to the notion of
software patents. But I still think that the document in question should
be published as Experimental:
- It's quite plain that this political view has never been adopted by IETF
consensus. (I also think it
Hate to say it, but the Subject says it all:
If you reject *any* standard that infringes on *any* patent, you will be
rejecting *standards*.
PLEASE talk to a real lawyer before playing one. Just about everything
dealing with communications and computing has *some* encumbrance.
Since it is
On Sun, 2007-10-28 at 09:05 -0700, Bill Fenner wrote:
RFC 2026, section 10.4.(D), gives boilerplate to add to a document
where there is known ipr:
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
If we create confusion by labelling everything RFC we are going to feel the ill
effects caused by that confusion.
I know we keep comming across the problem that the RFC numbers are welded into
the infrastructure and nobody seems to want STDs. But we still have a problem.
Perhaps a variant of
Folks, while attempting to use draft-williams-on-channel-binding in
the SASL working group, we came across an ambiguity.
In response to IETF last call comments we added the concept of a
unique prefix and a registry of prefixes for channel binding type. We
added a requirement that applications
Eric == Eric Rosen [EMAIL PROTECTED] writes:
Eric - I don't think the IETF considers this document offends my
Eric political point of view to be a legitimate reason for
Eric opposing the document. The degree of passion and/or
Eric repetition with which the political view is
Fellow IETF-ers.
We (Nominet) have published a position paper that examines the issues
currently preventing widespread adoption of DNSSEC with a special
focus on the issues involved in signing the root zone. We also
suggest a solution to signing the root that we believe balances the
Dear Roy and IETF-ers:
A quick reaction to this document:
Good contribution: at last there is a documented proposition for the
view that DNSSEC root signature is strictly a technical management issue.
This document uses a two-tiered organization for root key management,
respectively
*
* So who benefits most from the notice?
The lawyers.
Bob Braden
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00.txt
offers this text as a modification to RFC 2026:
A specification from which at least two independent and interoperable
implementations from different code bases have been developed, of
which at least one is
Keith Moore wrote:
For several reasons, it is difficult to imagine an IETF-wide procedure
that allows the existence of a patent to trump other considerations of
protocol feasibility and deployability:
Who suggested otherwise? It is not the existence of the patent that matters,
but its
Leslie == Leslie Daigle [EMAIL PROTECTED] writes:
I doubt I'll use the output in security protocols.
Leslie Leslie.
Leslie Original Message Subject: WG Review:
Leslie Performance Metrics at Other Layers (pmol) Date: Mon, 22
Leslie Oct 2007 14:15:02 -0400
At the Application Performance Metrics BoF in
Chicago, there was a lot of discussion about whether
or how to best capture expertise in the area of performance
metrics for application to IETF protocols.
There seemed to be 2 separate questions on the table:
1/ how, and
2/ whether
Although this may not be a popular opinion, I have to agree with James
here. Our goal is to have the widest acceptance of a given protocol
output from the IETF. One way is to have lots of open source
implementations.
One interesting side effect of the existence of an open source
implementation
I would offer that patents are NOT categorically evil.
Phil Zimmerman has applied for patents in ZRTP, specifically to ensure
that all implementations fully conform with the specification. Cost to
license for a conformant specification? $0. Cost to not really provide
privacy but claim to be
I admit to finding the discussion about Draft standards a bit
theoretical, given how few RFCs ever make it there. As a rough estimate,
http://www.rfc-editor.org/rfcxx00.html#Draft
shows a rate of 20 out of a 1000.
On Oct 29, 2007, at 3:20 PM, James M. Polk wrote:
Could we discuss this over on the IPR WG list, since the draft
responds to a specific request from the WG Chair?
Brian
On 2007-10-30 08:44, Henning Schulzrinne wrote:
I admit to finding the discussion about Draft standards a bit
theoretical, given how few RFCs ever make it there. As a rough
Eric Burger [EMAIL PROTECTED] writes:
One interesting side effect of the existence of an open source
implementation of a protocol is monoculture. We ran into a problem in
ifax year ago when it turned out that all eight independent
implementations all relied on the same library, thus
Eric Burger wrote:
I specifically applied for patents underlying the technology behind RFC
4722/RFC 5022 and RFC 4730 specifically to prevent third parties, who
are not part of the IETF process, from extracting royalties from someone
who implements MSCML or KPML.
That was a waste of your
At 04:48 PM 10/29/2007, Simon Josefsson wrote:
Eric Burger [EMAIL PROTECTED] writes:
One interesting side effect of the existence of an open source
implementation of a protocol is monoculture. We ran into a problem in
ifax year ago when it turned out that all eight independent
Steven Bellovin wrote:
We've all seen far too many really bad
patents issued, ones where prior art is legion. The (U.S.) patent
office seems to do a far better job of searching its own databases than
it does the technical literature.
I know there are many philosophical reasons why many
There are 2 people who own every right on computers
http://en.wikipedia.org/wiki/Charles_Babbage
and programming
http://www.agnesscott.edu/Lriddle/women/love.htm
All patents therafter are infringements of the work of
these two people.
Well even those two people built on the work of other
Steven M. Bellovin wrote:
You're obviously right in theory on this point. I wonder whether
you're right in practice. We've all seen far too many really bad
patents issued, ones where prior art is legion.
...
I think we can all agree that
stopping bad patents is a worthwhile goal,
Since application developers have developed many tricks to smooth out
some peculiarities of network-based protocols (e.g. jitter, delay, drops
and so on), it is very often hard to related the performance
measured/perceived at application layer with those of underlying layers.
If this WG
On Mon, 2007-10-29 at 18:26 -0700, Dave Crocker wrote:
Steven M. Bellovin wrote:
You're obviously right in theory on this point. I wonder whether
you're right in practice. We've all seen far too many really bad
patents issued, ones where prior art is legion.
...
I think we can
On Mon, 29 Oct 2007 17:53:35 -0700
Lawrence Rosen [EMAIL PROTECTED] wrote:
Steven Bellovin wrote:
We've all seen far too many really bad
patents issued, ones where prior art is legion. The (U.S.) patent
office seems to do a far better job of searching its own databases
than it does the
At 5:53 PM -0700 10/29/07, Lawrence Rosen wrote:
\The notion that each IETF working group has to approach patent issues on its
own, without help, is silly. Set an enforceable IETF patent policy for free
and open standards, and bring the technical community together through these
groups (and
The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'Definition of Events For Channel-Oriented Telephony Signalling '
draft-ietf-avt-rfc2833biscas-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks,
The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Revised Civic Location Format for PIDF-LO '
draft-ietf-geopriv-revised-civic-lo-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
44 matches
Mail list logo
