RE: 2026, draft, full, etc.
I agree, but only partly. A second pass on the documents does have a beneficial effect. This is particularly the case for older 'standards' where the documents simply don't match current requirements (no security, iana considerations for a start) and are often missing key folklore essential for interoperability. Where I think the process goes wrong is that it applies to documents, not protocols. A lot of crud goes through the mill in the name of avoiding recycling at proposed. And when a major revision of an existing protocol is done the revision goes back to proposed before being promited to draft. > -Original Message- > From: Eliot Lear [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 30, 2007 6:18 AM > To: Simon Josefsson > Cc: IETF Discussion > Subject: 2026, draft, full, etc. > > [I'm changing the subject and cutting off the references list > as we seem to have changed topic.] > > Simon, > > > DS designates a mature standard. If you read the > requirements in RFC > > 2026 for a mature standard it is clear that few of the modern IETF > > protocols live up to that standard -- you need to demonstrate > > interoperability between two completely independent > implementations of > > _all_ features in the protocol standard. > > > I think we can all agree that the calendaring standard is > mature. We are in the process of doing what I would consider > to be a relatively minor update to it, and yet it is only PS. > IMAPv4 is only PS and yet has MASSIVE deployment. LDAP is > only PS and is MASSIVELY deployed. SIP is all over the place > and it is only PS as well. And so it's pretty clear that > nobody cares about DS or IS. What's more, why should they? > What benefit does it bring to anyone to advance a standard to > DS? AND it's a whole lot of work. > > So why are we even having an argument about what gets stuck > into requirements for DS? Shouldn't we instead be > eliminating it entirely? > > Eliot > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Patents can be for good, not only evil
Phil's strategy here is not without issues. This was raised during the W3C discussion when IBM pointed out at length that a license fee can be considerably less of an inconvenience than certain Zero fee licenses. So for example a requirement that you can only implement a protocol using Java (or chose your language). Or use certain cipher suites, or a directory root controlled by the patent holder, or any number of similar schemes. Defensive patents are certainly an acceptable practice, one that I would like to see encouraged. At this point I believe that you would find 95% of corporate patent lawyers at Internet companies would rank defending against patent lawsuits as a much higher priority than recovering revenue. One of the problems I see here is that engineers can be dissuaded from applying for defensive patents as doing so is likely to lead to them being held up for ridicule on forums like Slashdot. This is particular the case with defensive security patents which make claims against specific attacks against a system. The point here being not to sell products that implement the attack but to prevent others from doing so. > -Original Message- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 5:16 PM > To: Keith Moore; [EMAIL PROTECTED] > Cc: ietf@ietf.org > Subject: Patents can be for good, not only evil > > 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 implementing ZRTP? Costly! > > 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. Cost to license? $0. Cost to sue someone who > infringes said third-party's IPR? That depends, but at least > we raised the cost of shutting down an IETF standard. > > Remember, just because *you* do not have IPR in an IETF > standard does not mean someone *else* has IPR in the > standard. If that someone else does not participate in the > IETF or, for that matter, happen to not participate in the > work group or, in reality, are not editors of a document, > they can fully apply their IPR against the standard once it issues. > > I like to have a little inoculation against that situation in > the stuff I submit. > > -Original Message- > From: Keith Moore [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 4:04 PM > To: [EMAIL PROTECTED] > Cc: ietf@ietf.org > Subject: Re: When is using patented technology appropriate? > > Lawrence Rosen wrote: > > 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 unavailability under license terms that allow > > implementation in > > *any* software. > > > _and_ its validity, _and_ its applicability, both of which > can be subjective and difficult to determine conclusively > without long delays > and excessive expense. so we have to make judgments. and by "we" I > mean individuals participating in IETF, not IETF itself. > > The more feasible and deployable the protocol, the more > important will > > > be FOSS implementations. > > > only relative to other protocols in the same space. > > granted that patents are the bane of any open > standards-making organization, because patents do exactly the > opposite of what open standards do. at the same time, we > can't let FUD about patents become a denial of service attack > to IETF efforts. > > Keith > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 2026, draft, full, etc.
> [I'm changing the subject and cutting off the references list as we seem > to have changed topic.] > Simon, > > DS designates a mature standard. If you read the requirements in RFC > > 2026 for a mature standard it is clear that few of the modern IETF > > protocols live up to that standard -- you need to demonstrate > > interoperability between two completely independent implementations of > > _all_ features in the protocol standard. > I think we can all agree that the calendaring standard is mature. We > are in the process of doing what I would consider to be a relatively > minor update to it, and yet it is only PS. It is less clear, however, that all of its many features have been implemented interoperabiy. > IMAPv4 is only PS and yet has MASSIVE deployment. The main barrier to IMAP moving to draft is the large number of normative references that first need to move first. Getting RFC 2822 to draft is a necessary first step and we're working on that. But what about TLS? The now-widespread use of TLS+plain has solved a lot of problems for appplications but has created a serious obstacle to standards track advancement. Perhaps a downreference exception needs to be made here, but if so that needs to be approved in advance because nobody is going to bother going through all the pain of documenting interoperability without first being sure that a normative reference issue isn't going to render their work meaningless. > LDAP is only PS and is MASSIVELY deployed. I suspect the main issue is the same as for IMAP. > SIP > is all over the place and it is only PS as well. And so it's pretty > clear that nobody cares about DS or IS. I really don't think that's true. The problem is rather than people have (correctly IMO) assessed that while the benefits of DS are real they just aren't worth the cost. The question, then, is whether or not the cost can be lowered without compromising the status, and if so, how. My personal opinion is that major loosening of the downref rules as well as less nit-picking on feature lists would help a lot without damaging the brand in any significant way. > What's more, why should they? > What benefit does it bring to anyone to advance a standard to DS? AND > it's a whole lot of work. > So why are we even having an argument about what gets stuck into > requirements for DS? Shouldn't we instead be eliminating it entirely? I agree with Brian that this isn't the answer. But the current situation isn't right either. We need to focus on what's important, which is real world interoperability. Things have gotten too complex for a more exhaustive academic approach to be viable. Ned P.S. I actually started working on a feature checklist for RFC 3501 at one point but after looking at the issues with normative refrences I simply gave up. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Non-participants [Re: Experimental makes sense for tls-authz]
> [By the way, when I find myself in a WG meeting I'm not prepared > for, I often have my head buried in the drafts being discussed, > so as to be able to understand the issues. Don't assume that a head > buried in a laptop is always doing email.] Has there been an assumption that these "non-participants" sending email have not read the tls-authz draft? I'ts impossible to be sure given the lack of technical content in the comments in question, but given that the call for comments that appeared on the FSF site basically said "write in and voice your opposition to the publication of tls-authz" and did not mention actually reviewing the specification, it seems reasonable to be skeptical. And even if they have read tls-authz it is hard to take comments containing oxymorons like "experimental standard" very seriously, since such comments are a strong indicator of lack of familiarity with our process or 2026 criteria. Again, I see no difference between what is happening on this list vs. what would happen in a F2F meeting, except that I've never witnessed a chair or AD say "Well, it is obvious you guys are all non-participants and therefore your hums will be ignored" in a F2F meeting. OTOH, I've seen plenty of F2F meetings where people were asked if they have actually read the draft and this information was definitely a factor in how things preceeded from there. And I agree with Frank's point about these emails. They have been unfairly classified as an "attack" or a DoS, perhaps to delegitimize their content. And this episode doesn't really compare to previous campaigns. I, OTOH, have to say that I agree with Scott Bradner's assessment that this is effectively a call to engage in censorship. I agree that some of the content of the emails is nonsensical, but the counter argument to them is that the document should be published because the IETF process has a slot into which it will fit. Or in other words, the IETF should publish it because it can. That does not seem like a good enough reason. Speaking as someone who previously sent in a message saying I support publication of tls-authz as experimental, now you're the one being unfair. I _never_ voice support or opposition for a specification I have not read and tls-authz is no exception. (And I doubt very much I alone have this policy.) In fact as it happens I not only reviewed the specification I even managed to make it to a WG meeting where the document was discussed some time back - unusual for me given that I don't track TLS work all that closely. I will add that the criteria I use in evaluting documents vary depending on the status that is sought. In this specific case I actually think the document is close to being of sufficient quality and more thatn sufficient utility to be approved as proposed were it not for the patent issue. The concerns I would have raised had there been no patent issue and had this document tried for proposed standard have to do with the use of URLs to access "large" SAML assertions and X.509 ACs. I'm always leery of protocols that can cause an agent to silently dereference a URL outside of a user's control. I think the possibility that such access needs to be controlled in some way might deserve some mention in the security considerations section. I'm also unsure if the warning against the possibility of a circular reference (the x509_attr_cert_url or saml_assertion_url refer to a some URL which requires tls-authz support in order to dereference) is quite strong enough. But these concerns didn't seem sufficiently serious to require attention prior to publication as experimental. I believe the main concerns with experimental specifications should be (a) Whether or not things are clear enough for meaningful experimentation to take place and (b) Whether or not the experimentation has been defined in such a way that it won't interfere with existing standards-compliant usage or any other experiements. And in my view this specification easily meets both of these criteria. (I note in passing that in my view the sender-id and SPF experiments taken together fail to meet the last of these criteria and IMO should not have been published without first being modified so there's no chance of them interfering with each other.) The one thing I wasn't sure of and did check for tls-authz was the size of the ExtensionType field. Had that field been small I would have been concerned about this extension wasting a valuable "slot". But since this is a 16 bit field there's no shortage of values and I cannot get excited about the possibility of wasting one. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 2026, draft, full, etc.
On 2007-10-30 23:18, Eliot Lear wrote: [I'm changing the subject and cutting off the references list as we seem to have changed topic.] Simon, DS designates a mature standard. If you read the requirements in RFC 2026 for a mature standard it is clear that few of the modern IETF protocols live up to that standard -- you need to demonstrate interoperability between two completely independent implementations of _all_ features in the protocol standard. I think we can all agree that the calendaring standard is mature. We are in the process of doing what I would consider to be a relatively minor update to it, and yet it is only PS. IMAPv4 is only PS and yet has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. SIP is all over the place and it is only PS as well. And so it's pretty clear that nobody cares about DS or IS. What's more, why should they? What benefit does it bring to anyone to advance a standard to DS? AND it's a whole lot of work. So why are we even having an argument about what gets stuck into requirements for DS? Shouldn't we instead be eliminating it entirely? Well, as you know Eliot, we tested the IETF's enthusiasm for tackling that discussion a couple of years ago, and found it lacking. I continue to believe that to keep the "running code" goal alive, we need something like the PS to DS promotion available, but we need to change things to make it more attainable in practice. But if you want to see progress, you're going to have to show a measure of consensus to the General AD. Comments on draft-carpenter-rfc2026-changes-01.txt are welcome. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 2026, draft, full, etc.
At 05:18 AM 10/30/2007, Eliot Lear wrote: [I'm changing the subject and cutting off the references list as we seem to have changed topic.] Simon, > DS designates a mature standard. If you read the requirements in RFC > 2026 for a mature standard it is clear that few of the modern IETF > protocols live up to that standard -- you need to demonstrate > interoperability between two completely independent implementations of > _all_ features in the protocol standard. I think we can all agree that the calendaring standard is mature. We are in the process of doing what I would consider to be a relatively minor update to it, and yet it is only PS. IMAPv4 is only PS and yet has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. DHCP is the best (worse?) example of this, IMO. It's been DS (meaning at least 2 independent implementations) for how many years now (5, 6 or 8+ years)? It's (as you say) MASSIVELY deployed. Yet it isn't a Full STD. That one had always caused me to pause about how serious IETFers are really about 2026 processes... SIP is all over the place and it is only PS as well. And so it's pretty clear that nobody cares about DS or IS. Actually some do care *AND* the IETF gets dinged on this one by those that aren't IETFers as not mature. These are the same (psst: idoits) that confuse Internet "Draft" with "Draft" Standard, somehow thinking each status is the same (...somehow). What's more, why should they? What benefit does it bring to anyone to advance a standard to DS? AND it's a whole lot of work. So why are we even having an argument about what gets stuck into requirements for DS? Shouldn't we instead be eliminating it entirely? Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
At 04:24 AM 10/30/2007, Simon Josefsson wrote: > 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" >> > implementations all relied on the same library, thus rendering the >> > "independent" implementations label difficult, to say the least. Why >> > were there no independent implementations? Because in this case, the >> > open source implementation was pretty good, and it was not worth >> > investing in a proprietary implementation. The result here has a really >> > bad side effect for the IETF: if there is a good open source, free >> > implementation, there will be no second implementation, resulting in it >> > being impossible for the standard to progress. >> >>But that is how it is supposed to work! If there is only one >>implementation, a standard is not mature enough to move to DS. You need >>to have at least two, preferably several more, completely independent >>implementations in order to quality-test a standard. > > but why does one or both have to be open source? > > Why can't both be commercial? DS designates a mature standard. If you read the requirements in RFC 2026 for a mature standard it is clear that few of the modern IETF protocols live up to that standard -- you need to demonstrate interoperability between two completely independent implementations of _all_ features in the protocol standard. Another (existing) requirement is that any patent licenses needs to be obtained through separate processes. I believe that a good way to demonstrate that the patent license process works is to require that a free software implementation exists. I strongly believe it should be possible to participate on the Internet without paying a software patent tax to some organizations. I believe you are arguing that the ends justify the means. In other words, because all the licensing has to be worked out (to become a DS), you believe a free implementation is the answer. I say it is not. Two commercial organizations can work out licensing and comply with this requirement - but you don't want that to be acceptable. I hold that this is what I'm referring to as "bad for the IETF" because corporations will either start involving themselves less in the IETF (directly affecting the IETF's revenue - which is already too low, and probably adversely affecting corporate sponsorship of meetings - which is already hard to acquire), and/or have fewer corporate participants care about DS and FS RFCs, because there is no incentive for them to do the work. BTW - if you believe a free (cost-wise) implementation be mandatory for elevation to DS, why don't you suggest the text be changed to say that? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
At 04:24 AM 10/30/2007, Simon Josefsson wrote: > I admit now s/now/not all PSs have IPR attached, but this is almost certainly > intended to kill any IPR from achieving DS. Is that what is intended > here? I don't believe that was the intention, but that's a question for Brian. I disagree that all PSs are patented (if that is what you meant). see above - I misspelled a word that means something else. sorry I've implemented several such standards without worrying about patents. I believe the majority of PSs are actually published without known patents. A search in the IETF IPR tracker should answer that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 2026, draft, full, etc.
Dave Cridland wrote: > On Tue Oct 30 10:18:08 2007, Eliot Lear wrote: >> What benefit does it bring to anyone to advance a standard to DS? AND >> it's a whole lot of work. >> > But it does do some good to review past specifications and note if > they're still ok, it does do some good to note that specifications are > solid, and it does do some good to say they're widely deployed. Sadly, > this information does not get captured anywhere. Not to mention the value of incorporating the results of implementation and deployment experience (though perhaps that's part of what you call reviewing past specifications). I suppose that incorporating experience, reviewing the specification, and the like can be done by cycling at PS forever, so it's not clear whether DS and IS really matter. However, it may be that those good things happen only by advancing a technology to DS. If so, then perhaps it's OK that doing so is "a whole lot of work" as Eliot says. After all, advancing an I-D to RFC is a whole lot of work, too, but we generally consider that process to be beneficial. Maybe we need to more clearly enunciate the benefits of advancing a technology to DS? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Patents can be for good, not only evil
Hi Eric, I generally agree, that patents are not *necessarily* evil ... just that they can be, so need to err on the side of caution. > 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 implementing ZRTP? Costly! Cannot resist: I believe it was Dean Willis that described this approach as "brilliantly evil" a couple of IETF meets ago... >;-> -- Peter "Eric Burger" <[EMAIL PROTECTED]> 29.10.07 17:16 To: "Keith Moore" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> cc: ietf@ietf.org Subject:Patents can be for good, not only evil 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 implementing ZRTP? Costly! 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. Cost to license? $0. Cost to sue someone who infringes said third-party's IPR? That depends, but at least we raised the cost of shutting down an IETF standard. Remember, just because *you* do not have IPR in an IETF standard does not mean someone *else* has IPR in the standard. If that someone else does not participate in the IETF or, for that matter, happen to not participate in the work group or, in reality, are not editors of a document, they can fully apply their IPR against the standard once it issues. I like to have a little inoculation against that situation in the stuff I submit. -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 4:04 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: When is using patented technology appropriate? Lawrence Rosen wrote: > 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 unavailability under license terms that allow > implementation in > *any* software. > _and_ its validity, _and_ its applicability, both of which can be subjective and difficult to determine conclusively without long delays and excessive expense. so we have to make judgments. and by "we" I mean individuals participating in IETF, not IETF itself. > The more feasible and deployable the protocol, the more important will > be FOSS implementations. > only relative to other protocols in the same space. granted that patents are the bane of any open standards-making organization, because patents do exactly the opposite of what open standards do. at the same time, we can't let FUD about patents become a denial of service attack to IETF efforts. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Patents can be for good, not only evil
Eric Burger wrote: 5. I am now facing US$ 250,000 minimum, US$ 1,000,000 typical, in legal fees to invalidate the patent issued in step 3. From what I've been told, $1M is more like the entry fee for this contest, if the patent holder has any tenacity at all. And if they do, it gets a lot higher, quickly. 6. I would win the case, because I have the prior art. However, I am not stupid, so I begrudgingly pay $40,000 for the privilege of using my own invention and not paying tons of legal fees. Again, from what I've been told, your assertion is far too optimistic. The realities of challenging a patent are not nearly that deterministic. At a minimum, the human frailties of judges and juries makes it a gamble whether they will agree that a particular piece of prior art is, indeed, prior art. Let's remember that patents are about technical things, and judges and juries -- no matter how diligent and well-intentioned, are not classed as 'skilled in the art'. So their understanding of issues and details is typically going to be significantly constrained, no matter how well the issues are presented to them. All of which serves to strengthen your argument in favor of defensively patenting the prior art. This is why I call it inoculation. US$ 12,000 in legal and filing fees today has a 20x - 80x return on investment protection. But that's real money for an individual to spend. And real hassle. It's asking rather a lot to expect folks to a) think of their work as prior art, b) take the time, and c) spend the money just for the greater good. That's assuming they can afford the time and money. Is the system stupid? Unquestionably. Is it the system? Yes. Public review during the final stages of patenting has struck me as a particularly constructive effort. Whether it works, I've no idea. As noted, patent officers are human too. But from what I've seen of patent file wrappers, the patent officers generally do seem to look for real prior art, albeit not as widely as we would wish. But, then, they operate under serious time and resource constraints. Input from the public would help counter this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Non-participants [Re: Experimental makes sense for tls-authz]
On Oct 27, 2007, at 2:52 PM, Brian E Carpenter wrote: On 2007-10-28 06:36, Andrew Newton wrote: On Oct 27, 2007, at 11:00 AM, David Morris wrote: Well for starters, the drive-by hummers have to sit through the session and be present for the discussion (note I intentionally did not say listen). They have to demonstrate enough interest in the IETF process to actually pay the costs of attending the session. Most of the drive-by hummers have their head buried in their email or other laptop work, so the expense they run for looking up to hum once or twice isn't at all onerous. At least in this case, the drive-by emailers had to spend some thought cycles on the email they composed. [By the way, when I find myself in a WG meeting I'm not prepared for, I often have my head buried in the drafts being discussed, so as to be able to understand the issues. Don't assume that a head buried in a laptop is always doing email.] Has there been an assumption that these "non-participants" sending email have not read the tls-authz draft? Again, I see no difference between what is happening on this list vs. what would happen in a F2F meeting, except that I've never witnessed a chair or AD say "Well, it is obvious you guys are all non-participants and therefore your hums will be ignored" in a F2F meeting. And I agree with Frank's point about these emails. They have been unfairly classified as an "attack" or a DoS, perhaps to delegitimize their content. And this episode doesn't really compare to previous campaigns. I agree that some of the content of the emails is nonsensical, but the counter argument to them is that the document should be published because the IETF process has a slot into which it will fit. Or in other words, the IETF should publish it because it can. That does not seem like a good enough reason. Secondly, WG chairs and the responsible AD are well able to notice that a meeting has been packed, and to interpret any straw poll or hum accordingly. Well, I'm not sure how often it happens. I can only think of 3 incidents in these past many years. But in a more recent one, the ADs seemed to either be unaware or unprepared. -andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Patents can be for good, not only evil
--On 29. oktober 2007 17:53 -0700 Lawrence Rosen <[EMAIL PROTECTED]> wrote: The notion that each IETF working group has to approach patent issues on its own, without help, is silly. It's also a straw man. RFC 3669. You may argue that we can do better, but the argument that there is "no help" is silly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: 2026, draft, full, etc.
> I've suggested before that the advancement of a specification > is a highly overloaded action - it implies that the IETF > thinks it's a good idea, it implies that the specification is > sound, it implies it's well deployed. Does the IETF have a way to communicate that a specification is a good idea with a sound specification and that is well deployed? For that matter, does the IETF have a way to make that determination? One way in which the IETF has conveyed additional info in the past is by designating RFCs as part of a BCP or FYI series. Similar mechanisms could be used to convey that a specification is more than just a plain old humdrum RFC. The point of all this being, that if the IETF does communicate that certain RFCs are of a higher class than others, it makes it harder for others to misunderstand the meaning (or mislead others about the meaning) of RFC status for some particular protocol. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Patents can be for good, not only evil
Larry Sorry that I answered before seeing that others had already said the same thing. However, even after reading your subsequent email, I am unconvinced. Requesting a re-examination is a lengthy process, and if unsuccessful further strengthens the party holding the patent (as it has gone through 2 examinations). On the other hand, the patent holder can force you to respond in a Texas court within 30 days, incurring the costs of representation. BTW, this kind of patent busting is hardly new. There used to be a "patent busters" site where bounties were offered. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Patents can be for good, not only evil
>> 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 time and money. Publication of those inventions by you, at zero cost to you and others, > would have been sufficient to prevent someone else from trying to patent them. Quite untrue, in my experience. The patent examiners almost never find prior art from the open literature. Their decisions are based on their databases of existing patents. So althought you are quite right in principle, open publication has low probability of blocking someone from getting a patent. Fighting a granted patent on the base of open publication prior art would cost much more. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Patents can be for good, not only evil
More to the point, patent law is one of the only two areas of law where you are guilty until you can prove yourself innocent. The other is tax law. Yes, I could have simply published the work. That establishes prior art. However, let us consider this very real (I have experienced it) scenario. 1. I invent something. It is generally useful, yet I don't think I'll get rich on the idea. 2. I publish the invention, to put a stake in the ground, hoping to put the invention into the commons. 3. Someone else, without knowledge of my publication, invents something similar, or the same, and patents the invention. 4. That someone else sues people over my invention. 5. I am now facing US$ 250,000 minimum, US$ 1,000,000 typical, in legal fees to invalidate the patent issued in step 3. 6. I would win the case, because I have the prior art. However, I am not stupid, so I begrudgingly pay $40,000 for the privilege of using my own invention and not paying tons of legal fees. This is why I call it inoculation. US$ 12,000 in legal and filing fees today has a 20x - 80x return on investment protection. Is the system stupid? Unquestionably. Is it the system? Yes. On 10/30/07 2:52 AM, "Dean Anderson" <[EMAIL PROTECTED]> wrote: > [I am rather getting tired of 100+ email addresses in the to: field. > Pine also doesn't allow reply-all to the bcc: field. I'm thinking of > creating a new list of everyone that posts to the IETF list. Thoughts?] > > > On Mon, 29 Oct 2007, Lawrence Rosen wrote: > >> 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 time and money. Publication of those >> inventions by you, at zero cost to you and others, would have been >> sufficient to prevent someone else from trying to patent them. Next >> time, get good advice from a patent lawyer on how to achieve your >> goals without paying for a patent. > > This was true only in the U.S., and will not be true once the senate > passes the first-to-file legislation that recently passed the house. > > Once first-to-file is put into effect, everyone has to race to the > patent office. It doesn't matter who invented what. However, years ago > legislation passed that grandfather'd the original inventor; the > original inventor can't be charged fees. However, the original inventor > can't change the royalty structure imposed by the first filer. > >> For those here who keep asking for protection against patents in >> standards, there is no more effective technique than through a revised >> IPR policy that prohibits patent-encumbered standards from gaining the >> IETF brand in the first place. > > This sounds like a good idea at first. However, the LPF has long > promoted protective patents: > http://lpf.ai.mit.edu/Patents/mutual-def.html > > It would be a bad idea to prohibit all patents in standards. > > In a first-to-invent regime, the law still favors one with a patent, > since it gives one a cross-licensing opportunity to settle a dispute > with a similar, infringed patent, even if one uses their patent only > protectively. > > In a first-to-file regime, protective patents are absolutely necessary. > The U.S. is treaty-bound (GATT) to implement first-to-file patent law. > The House recently passed this legislation, and I think it is expected > to pass the Senate, but the Senate hasn't yet voted. > > I'm a little uneasy about changing the IETF patent policy. First, the > current policy has exactly the right idea: consider the patent and its > license, and make a smart decision. If one follows the rules honestly, > the rules are just right. > > Second, the people most in favor of changing it are the very ones who > silenced me, and who are generally pro-patent. They were the same ones > who said that RFC 3979 wasn't the policy of the IETF. When we look > closely at the proposed document, it has ambiguities (already noticed by > others) that don't distinguish free-as-in-beer from free-as-in-freedom. > > The only thing I might recommend changing about the present policy is to > add a definite mandatory penalty for deceiving the IETF. > > I think we need more honesty and accountability in the leadership of the > IETF before we make such changes. > > --Dean > > Dean Anderson > President of the League for Programming Freedom > > > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the
Re: 2026, draft, full, etc.
On Tue Oct 30 10:18:08 2007, Eliot Lear wrote: I think we can all agree that the calendaring standard is mature. We are in the process of doing what I would consider to be a relatively minor update to it, and yet it is only PS. IMAPv4 is only PS and yet has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. SIP is all over the place and it is only PS as well. And so it's pretty clear that nobody cares about DS or IS. What's more, why should they? Well, we don't, but mostly because we tend to know what the actual status of a particular protocol is. Usually. But not always, especially when it falls outside our area of expertise, and far more importantly, people not directly involved in the IETF at all don't know. I've suggested before that the advancement of a specification is a highly overloaded action - it implies that the IETF thinks it's a good idea, it implies that the specification is sound, it implies it's well deployed. What benefit does it bring to anyone to advance a standard to DS? AND it's a whole lot of work. But it does do some good to review past specifications and note if they're still ok, it does do some good to note that specifications are solid, and it does do some good to say they're widely deployed. Sadly, this information does not get captured anywhere. So why are we even having an argument about what gets stuck into requirements for DS? Shouldn't we instead be eliminating it entirely? And lose even the small amount of information it does give people? I think we'd do better to decide what information we want to be able to provide, and provide it, rather than wondering how many levels of overloaded information we should have. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
2026, draft, full, etc.
[I'm changing the subject and cutting off the references list as we seem to have changed topic.] Simon, > DS designates a mature standard. If you read the requirements in RFC > 2026 for a mature standard it is clear that few of the modern IETF > protocols live up to that standard -- you need to demonstrate > interoperability between two completely independent implementations of > _all_ features in the protocol standard. I think we can all agree that the calendaring standard is mature. We are in the process of doing what I would consider to be a relatively minor update to it, and yet it is only PS. IMAPv4 is only PS and yet has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. SIP is all over the place and it is only PS as well. And so it's pretty clear that nobody cares about DS or IS. What's more, why should they? What benefit does it bring to anyone to advance a standard to DS? AND it's a whole lot of work. So why are we even having an argument about what gets stuck into requirements for DS? Shouldn't we instead be eliminating it entirely? Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Patents can be for good, not only evil
> That was a waste of your time and money. Publication of those > inventions by you, at zero cost to you and others, would have > been sufficient to prevent someone else from trying to patent > them. Next time, get good advice from a patent lawyer on how > to achieve your goals without paying for a patent. Perhaps he did consult a lawyer and learned that by patenting them he now has the ability to sue any non-licenced implementors in court, and can take away a share of any earnings that they made with their non-licenced implementation. That is not possible merely by publishing first. Law is every bit as complex as network protocols or application programming. It is better to consult with an expert in the field before making assumptions. I am not a lawyer. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
"James M. Polk" <[EMAIL PROTECTED]> writes: > 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" >> > implementations all relied on the same library, thus rendering the >> > "independent" implementations label difficult, to say the least. Why >> > were there no independent implementations? Because in this case, the >> > open source implementation was pretty good, and it was not worth >> > investing in a proprietary implementation. The result here has a really >> > bad side effect for the IETF: if there is a good open source, free >> > implementation, there will be no second implementation, resulting in it >> > being impossible for the standard to progress. >> >>But that is how it is supposed to work! If there is only one >>implementation, a standard is not mature enough to move to DS. You need >>to have at least two, preferably several more, completely independent >>implementations in order to quality-test a standard. > > but why does one or both have to be open source? > > Why can't both be commercial? DS designates a mature standard. If you read the requirements in RFC 2026 for a mature standard it is clear that few of the modern IETF protocols live up to that standard -- you need to demonstrate interoperability between two completely independent implementations of _all_ features in the protocol standard. Another (existing) requirement is that any patent licenses needs to be obtained through separate processes. I believe that a good way to demonstrate that the patent license process works is to require that a free software implementation exists. I strongly believe it should be possible to participate on the Internet without paying a software patent tax to some organizations. > So few PSs become DSs, I believe this will almost certainly make > progression from PS to DS slower. Is that what we want? I believe it will lead to better quality DS standards. The reason few PSs become DSs is, in my experience, not because a lack of free implementations, but rather that nobody cares enough to go through the pain of interop testing. The requirements for DS are pretty high already, which can be discussed as a separate issue, but this draft is only a marginal change. My impression is that your problem really is that few documents move to DS, not that a free implementation should be required. > I admit now all PSs have IPR attached, but this is almost certainly > intended to kill any IPR from achieving DS. Is that what is intended > here? I don't believe that was the intention, but that's a question for Brian. I disagree that all PSs are patented (if that is what you meant). I've implemented several such standards without worrying about patents. I believe the majority of PSs are actually published without known patents. A search in the IETF IPR tracker should answer that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
