Re: Diversity of IETF Leadership
On 03/19/2013 11:04 PM, Stewart Bryant wrote: Margret this is the IETF, it regularly sets aside law to create its own lies about what it is and is not capable of in a legal context - but that is all about to change I think... Todd On 19/03/2013 12:59, Margaret Wasserman wrote: On Mar 12, 2013, at 2:24 PM, Dan Harkins dhark...@lounge.org wrote: I'd love to get out of this rat hole. Perhaps the signatories of the open letter can restate the problem they see so it isn't made in terms of race and gender. The letter specifically mentioned the axes of race, gender, geographic location and corporate affiliation, so the letter was not only about race and gender. Other people have mentioned other pertinent axes in the e-mail discussion, such as industry segment and background/experience. I don't think it is possible for remove race and gender from the list of axes, though, since there is a notable lack of diversity in those areas. Margaret As I pointed out on an earlier thread, the relevant EU policy body, which I assume has a lot of expertise on this, defines the following protected characteristics, i.e. characteristics that you are NOT permitted to discriminate on in the EU: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. Stewart
Re: Diversity of IETF Leadership
I would suggest John that the real diversity the IETF needs is transparency in its process and a competent IPR rule set which meets the same set of legal hurdles people do in the commercial world so to speak. I would also suggest that the idea of splitting all of these contractually binding practices into a set of technical publications is inherently insane and has lead to the fiasco that we have today. What the IETF needs is a simple set of documents that do not require a free wall to post the various components on to develop a proper reliance map. Just my own two cents though. Todd On 03/20/2013 06:30 AM, John C Klensin wrote: --On Wednesday, March 20, 2013 06:53 -0400 Margaret Wasserman m...@lilacglade.org wrote: ... I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret, While I am very much in favor of a more diverse IETF population and leadership, the above, especially when combined with Martin Rex's later comment, is part of the reason why I see the problem as terribly difficult and not yielding easily to petitions, design teams, instructions to confirming bodies (particularly problematic as other discussions have shown), or good intentions. As a specific example, I think the IETF would be considerably strengthened by more diversity in corporate affiliations and industry segments as you suggest above. As with gender diversity, my impression is that we are getting more homogeneous rather than more diverse. One of the problems is time commitment and associated costs. For many corporations, most startups, and a significant fraction of actual individual participants, service in leadership positions is feasible only if those positions are really part-time and significant attention is paid to either cost containment or spreading marginal costs around the community. Yet the IESG (and, to a slightly lesser extent, the IAB) have tended to assign more and more work and responsibility to themselves, If we want more diversity along corporate, role, and related economic axes, we need (as others have pointed out) to shrink the jobs. In the IESG's case, that may require reducing the number of WGs we think we can operate in parallel. Unfortunately, there are many reasons to continue to _expand_ the jobs: on a point basis, it will always be easier to add tasks to existing leaders than to consider whether those tasks are really necessary, to consider sunsetting other tasks, or to organize and manage alternate ways to get them done. It also isn't clear that the community cares: I note that the recent effort to allow the IAB and IESG to appoint people other than the Chairs to serve on the IAOC/Trust, and an earlier one to separate the IAOC and the Trust, went exactly nowhere. On the other hand, if we are serious, I think it needs to be something that Nomcoms are committed (preferably without more rules) to enforce by asking candidates their positions on job-shrinking and by retiring incumbents who contribute to job-expansion. Those expansions are perhaps also influenced by the observation that, if the incumbents have the time and support for an expanded role, such expansion doesn't seem to be harmful. That is part of a classic example of why already-homogeneous organizations tend to become even more homogeneous, at leat in the absence of disruptive changes. best, john
Re: Diversity of IETF Leadership
On 03/20/2013 07:16 AM, Jorge Contreras wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.org mailto:m...@lilacglade.org wrote: Jorge - did I miss something here - isnt this your job? If not why are you here? Let me respond that further - I believe that there are any number of both privacy and transparency counsel's in the movement so to speak who would love to work with such a body to create a transparent set of participation rules UNDER THE CURRENT PARTICIPATION MODELS AS BROKEN AS THEY ARE... Didnt you file an ID yourself not to long ago? In fact I am betting Professor you know any number of Grad Students who would love such a job if you catch my drift. Todd Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com mailto:stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. What records *do* exist regarding the identify of IETF leadership? Is there a central repository of at least names/companies of IESG members and/or WG leaders?
Re: Less Corporate Diversity
On 03/20/2013 12:18 PM, Eric Burger wrote: How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the latter, but there is not much we can do about the former. Sure you can - you can put in place formal requirements for disclosure and actually make licenses which are recallable for frauds or other bad acts in the process. The issue isnt whether the goal of the IETF is a laudable one or not - it clearly is, the issue is whether the IETF itself is responsible for actions which its infrastructure is used to control are allowed or not and what the issues for threshold of damages are. Bluntly this IETF has no statistical idea on any of these things because it has intentionally put in place controls which are either too complex to implement or are glad-handed and ignored like the BCP78/79 rules which say All parties speak regularly with their sponsors legal departments to keep them abreast on changes or things of interest in the standards process... (yeah right...). No really - its about time everything here got locked down so everything is open and a little-guy really can submit and promulgate a technology through standardization. Todd
Re: Does being an RFC mean anything?
Lawrence Rosen wrote: Because Larry - many of those here owe their ongoing $$$ livelihood to the lie the IETF has become. And so what you are suggesting is increasing the rolls of the unemployed by adding these individuals who's whole existence is the IETF. Its also these people in my opinion that make the IETF the laughingstock its become as you so rights notice that RFC's and the process for creating standards has degraded into a model where there really is no standard. Just my two cents Todd Glassey The recent threads about draft-housley-tls-authz have taught me something I didn't know about IETF, and I don't like what I've learned. There are, it appears, many types of IETF RFCs, some which are intended to be called Internet standards and others which bear other embedded labels and descriptions in their boilerplate text that are merely experimental or informational or perhaps simply proposed standard. One contributor here described the RFC series as a repository of technical information [that] will be around when I am no longer around. The world is now full of standards organizations that treat their works as more significant than merely technical information. Why do we need IETF for that purpose? If all we need is a repository of technical information, let's just ask Google and Yahoo to build it for us. Maybe our Internet standards should instead be created in an organized body that pays serious attention to the ability of the wide world to implement those standards without patent encumbrances. But even if IETF isn't willing to amend its patent policy that far—and most SDOs still aren't, unfortunately—at the very least we should take our work seriously. When someone proposes a serious RFC, we should demand that the water around that RFC be swept for mines—especially **disclosed** patent mines that any serious sailor would want to understand first. If IETF isn't willing to be that serious, maybe we should recommend that our work go to standards organizations that do care? As far as my time to volunteer for a better Internet, there are far better ways to do it than listening here to proposals that are merely technical information. At the very least, separate that into a different list than IETF.org so I know what to ignore! By the way, many of the same companies and individuals who are involved here in IETF are also active participants in W3C, OASIS, and the new Open Web Foundation, all of which organizations pay more attention to patents and the concept of open standards than what IETF seems to be doing here. So let's not be disingenuous, please. Almost everyone here has previous experience doing this the right way. /Larry Lawrence Rosen Rosenlaw Einschlag, a technology law firm (www.rosenlaw.com http://www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Question about the meaning of the following boilerplate statement...
Since this appears as a part of the legal boilerplate on a I-D I have three questions to ask.. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. So then by US Law they are copyright under the US Copyright act since they are published by an agent in located in the US. The also are constrained by a set of steps and processes for those working groups as well including th the IETF's document templates. Note that other groups may also distribute working documents as Internet- Drafts. OK - let me ask the questions about this ambiguous block of text: 1) Is the Term of Art Internet-Draft a trademark of the IETF? - let me answer that question - NO... Internet_draft:__http://tess2.uspto.gov/bin/showfield?f=tocstate=4009%3Ai60kv1.1.1p_search=searchssp_L=50BackReference=p_plural=yesp_s_PARA1=p_tagrepl~%3A=PARA1%24LDexpr=PARA1+AND+PARA2p_s_PARA2=Internet_Draftp_tagrepl~%3A=PARA2%24COMBp_op_ALL=ANDa_default=searcha_search=Submit+Querya_search=Submit+Query Internet-Draft yields one filer - and it was done last year in 2008- http://tess2.uspto.gov/bin/showfield?f=docstate=4009:i60kv1.3.1 2) OK - so we were told that the TRUST had taken care of this I thought. But it clearly has not been - so then let me also ask why was this not handled years ago by the Secretariat's office. 3) If others are allowed to publish Internet-Drafts (as a Term of Art) does this mean they are republishing the IETF's IP's or that they are running a system competitively to the IETF's operations? The reason I bring this up is that this one paragraph can be interpreted to mean that All of the IETF's Proprietary processes are up for grabs just like its network IP. This is true since the creation of an Internet-Draft (the object codified in the term of art Internet-Draft by those process documents defining the IETF's process) is created though a specific set of defined steps and the ability for others to publish Internet-Drafts means that they also can use those process steps. If #3 was the intent then it needs to be disclosed to the sponsor's formally - since the IP rights being effected or controlled through the 'contribution' are theirs. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Question about the meaning of the following boilerplate statement...
TSG wrote: Since this appears as a part of the legal boilerplate on a I-D I have three questions to ask.. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. So then by US Law they are copyright under the US Copyright act since they are published by an agent in located in the US. The also are constrained by a set of steps and processes for those working groups as well including th the IETF's document templates. Note that other groups may also distribute working documents as Internet- Drafts. OK - let me ask the questions about this ambiguous block of text: 1) Is the Term of Art Internet-Draft a trademark of the IETF? - let me answer that question - NO... Internet_draft:__http://tess2.uspto.gov/bin/showfield?f=tocstate=4009%3Ai60kv1.1.1p_search=searchssp_L=50BackReference=p_plural=yesp_s_PARA1=p_tagrepl~%3A=PARA1%24LDexpr=PARA1+AND+PARA2p_s_PARA2=Internet_Draftp_tagrepl~%3A=PARA2%24COMBp_op_ALL=ANDa_default=searcha_search=Submit+Querya_search=Submit+Query Internet-Draft yields one filer - and it was done last year in 2008- http://tess2.uspto.gov/bin/showfield?f=docstate=4009:i60kv1.3.1 2) OK - so we were told that the TRUST had taken care of this I thought. But it clearly has not been - so then let me also ask why was this not handled years ago by the Secretariat's office. 3) If others are allowed to publish Internet-Drafts (as a Term of Art) does this mean they are republishing the IETF's IP's or that they are running a system competitively to the IETF's operations? The reason I bring this up is that this one paragraph can be interpreted to mean that All of the IETF's Proprietary processes are up for grabs just like its network IP. This is true since the creation of an Internet-Draft (the object codified in the term of art Internet-Draft by those process documents defining the IETF's process) is created though a specific set of defined steps and the ability for others to publish Internet-Drafts means that they also can use those process steps. Sorry - I forgot to mention why this was important - they (as in anyone who needs one) could theoretically publish an Internet-Draft, properly vet it on a private list and then build and run the interoperability testing for that protocol and declare it an IETF-Standard, and legally speaking I am betting the Court's would find it to be exactly that. This would support the creation of Internet-Drafts and RFC's which never was seen by the IETF or its membership because of this licensing terminology they could do this by creating a protocol between two players and vetting it privately between them. It is also arguable that the IETF could be forced to take formal notice of that RFC's number and respect it's issuance since it itself created this potential through the licensing models put in place by the Unholy Twins (BCP78 and BCP79) and their successors Someone planning to issue their own IETF-Standard would merely set up an internal mailing alias to meet the WG Mailing List requirement and then vet the private protocol internally on that list. They can also change the licensing rights on this as well based on the ability to use the work and create derivatives of it, the licensing boilerplate on documents and the copyrights and even NoteWell can be turned off for these private groups. The net of this is that the IETF has given itself away - and anyone can now run their own little IETF as a private operation. Hey even the old IESG trademark was formally abandoned and even though it was owned by a real-estate consortia the abandonment means that anyone can call themselves the IESG and issue a formal standard. http://tess2.uspto.gov/bin/showfield?f=docstate=4001:e8rlnd.2.1 If #3 was the intent then it needs to be disclosed to the sponsor's formally - since the IP rights being effected or controlled through the 'contribution' are theirs. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Current mailbombing is instigated by FSF
Dean Anderson wrote: Unfortunately, Todd's delicate sarcasm is probably lost on most... The method was determined by the IETF. The last call is a public comment period to gage consensus. There is nothing wrong with the method of the FSF in participating. Sure there is Dean - let me propose a theory here... The theory is that the formal agreement to issue the standard was made years ago and anything that interferes with that for any reason other that 'technical failure of the vetting, interoperability testing, or documentation process' constitutes an unethical action of tortuous interference in a preexisting contractual relationship between the IETF and the Standards Development contact's relying parties and *** MUST *** be rebuked by the IETF. Further, at this point the issue of whether to issue the standard has NOTHING to do with whether its patented or not and who owns that patent. Jorge as the IETF's attorney I suggest that you respond to this. My statement here is that if that vetting has finished and that instance of the vetting has interoperability testing done for it, and that testing satisfies the specification the WG agreed on, then the IETF's process has been met and the IETF is contractually bound to issue the Standard - PERIOD. No ands, no if's and no buts... no fricking whining but its patented. It just doesnt matter now whether its patented or not, the WG wasn't decieved and they agreed to do the work. If the IETF has a contract with the WG and its sponsors to issue that standard then it must meet that and anyone interfering with the issueance of a Technology Standard with a patent as its basis without participating in the WG's operations, is interfering with that contracts completion. Todd This rabble rousing about methods is nonsense, generated by Hallam-Baker, Crocker, Chiappa, and a number of other people who are known to be either opposed to the FSF or pro-patent. They are trying to make an argument that might be accepted by anti-patent people such as Mr. Bormann, while lying about both the IETF process and about their real motives. RFC 2026 defines last call as: Last-Call - A public comment period used to gage the level of consensus about the reasonableness of a proposed standards action. (see section 6.1.2) The FSF, and everyone else, has a __RIGHT__ to participate in a PUBLIC COMMENT PERIOD. Another argument that has been made is that it is somehow invalid to oppose the draft for patent licensing reasons. The existance of patents and terms of patents licenses must be disclosed according to RFC3979, and according to the assurance made by every author in the preface of a draft. So these reasons are proper reasons to oppose a draft. When pro-patent forces argue that RFC3979 isn't the policy of the IETF, they are merely being dishonest. --Dean On Fri, 27 Feb 2009, TSG wrote: Carsten Bormann wrote: http://www.fsf.org/news/reoppose-tls-authz-standard While I have a lot of sympathy for the cause, I have very little sympathy for the methods. I have NO sympathy for the cause. Rendering a mailing list that might be useful for actually resolving the issue inoperative by a campaign is idiotic. Somebody from I* (the IETF chair may not be the right person this time) should call them and explain that this is not the way to win friends and impress people. Gruesse, Carsten PS: kill-filing messages CCed to campai...@ietf.org might help a bit. I don't know if the procedures allow to do this at the mailing list level. Boy do I agree with you - The creation of a standard *** should *** have nothing to do with IP rights or licensing. The creation of any standard should JUST be based on whether proper vetting happened and whether the minimum number of ports was created and formally tested for interoperability. Anyone - and I mean ANYONE should be able to get a Standard by making the steps happen. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Current mailbombing is instigated by FSF
Carsten Bormann wrote: http://www.fsf.org/news/reoppose-tls-authz-standard While I have a lot of sympathy for the cause, I have very little sympathy for the methods. I have NO sympathy for the cause. Rendering a mailing list that might be useful for actually resolving the issue inoperative by a campaign is idiotic. Somebody from I* (the IETF chair may not be the right person this time) should call them and explain that this is not the way to win friends and impress people. Gruesse, Carsten PS: kill-filing messages CCed to campai...@ietf.org might help a bit. I don't know if the procedures allow to do this at the mailing list level. Boy do I agree with you - The creation of a standard *** should *** have nothing to do with IP rights or licensing. The creation of any standard should JUST be based on whether proper vetting happened and whether the minimum number of ports was created and formally tested for interoperability. Anyone - and I mean ANYONE should be able to get a Standard by making the steps happen. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
Lawrence Rosen wrote: Steven, thanks very much for your email. My comments are below. /Larry Larry - it is inappropriate for the IETF to be creating hurdles for those that are unwilling to support the mandatory new licensing requirements considering those are not part of the original or updated charters to the IETF itself. Nor is it possible to force those who already made their standards through RFC2026 as to these newly created terms and conditions for the same service. Todd Glassey -Original Message- From: Steven M. Bellovin [mailto:s...@cs.columbia.edu] Sent: Wednesday, February 18, 2009 11:45 AM To: lro...@rosenlaw.com Cc: ietf@ietf.org Subject: Re: Proposal to create IETF IPR Advisory Board On Tue, 17 Feb 2009 19:24:20 -0800 Lawrence Rosen lro...@rosenlaw.com wrote: Ted Ts'o wrote: So you've done the equivalent of submit Windows source code and assume that it can be ported to a Unix system left as an exercise to the reader care to give a detailed suggestion about *how* it could be revised to work with the IETF's more open procedures, and still be useful in terms of meeting your stated goals? I've made no such assumptions. I've submitted a couple of process documents from W3C that can be modified easily to fit the IETF model. I thought John and Steven would be satisfied with a rough draft. Sort of like Windows might provide a model for a Linux open source program, without the actual code being yet written. :-) Now that I've submitted this draft, I refuse to be told it isn't a draft, although I admit it isn't in the proper format. Any process bigots want to comment on that flaw tonight too? I specifically said that the W3C Patent and Standards Working Group (PSIG) charter (http://www.w3.org/2004/pp/psig/) and *section 7* of the W3C Patent Policy (http://www.w3.org/Consortium/Patent-Policy-20040205/) would be models for an IETF IPR Advisory Board. Neither of those specific document sections implies anything mandatory about RAND or royalty-free or any other of the political patent battles that divide us. They are merely open process descriptions, just like a draft here ought to be. I think it's a fair start, though I note that 7.5.3 carries with it a fairly strong bias towards royalty-free terms. But let me translate. [LR:] I share that bias, but that's an IETF battle for another day. For now, I'm glad that you think of this as a fair start. Rather than a standing board (which was what I thought you had intended), [LR:] I had indeed intended a standing board, and still do. Why have to agitate and recruit an expert team over every question, when a simple question referred to an IPR Advisory Board for an answer will probably suffice? But like most of your points in this paragraph, it's open for discussion you're suggesting (translated IETF terms) that when a WG encounters a patent thought to be related, a group will be formed [LR:] Or already exists consisting of the AD, the WG chair(s) ex officio, representatives of the WG (presumably designated by the chair(s)), perhaps an IAB liason [LR:] No comment. Up to you. -- and the IETF patent counsel. [LR:] Be very careful. No attorney who can be deemed to speak on behalf of IETF regarding patents should be there opining IETF's opinion about actual patents. Instead, I recommend that we have an invited (and probably open) selection of other attorneys who are willing to sign up and actually participate as individuals, not representing specific clients and speaking with appropriate liability caveats. For process purposes, however, the IPR Advisory Board can probably be chaired by an IETF patent counsel just to make sure everyone behaves We'll have to see how many brave attorneys are actually willing to participate in the entire IETF community's behalf, but if W3C is an example, we'll find lots of willing attorneys. :-) What is the analog to representatives of each member organization? Volunteers not from the WG? Selected by whom? The usual IETF practice would be appointment by the AD and/or the IAB, I suspect. [LR:] ...And even some non-attorneys; I'm not prejudiced In light of IETF's openness, anyone who is willing to sign up and actually participate, although I think most engineers will find the mailing list itself boring. Mostly it would consist of people reading the technology proposals, reading the patent disclosures, and opining about whether they match up. No guarantees or warranties. Just experts cooperating to advise non-experts so we can get IETF work done. Let's keep those discussions off the WG lists (where they distract everyone unnecessarily) and onto a single IPR Advisory Board (with people who actually like reading patent stuff and probably aren't just talking through their _). What would the possible alternatives be? The W3C version has a strong bias towards royalty-free,
Re: Proposal to create IETF IPR Advisory Board
Steven M. Bellovin wrote: On Wed, 18 Feb 2009 13:17:39 -0800 Lawrence Rosen lro...@rosenlaw.com wrote: Rather than a standing board (which was what I thought you had intended), [LR:] I had indeed intended a standing board, and still do. Why have to agitate and recruit an expert team over every question, when a simple question referred to an IPR Advisory Board for an answer will probably suffice? But like most of your points in this paragraph, it's open for discussion The advantage of a per-WG board is that members would likely have familiarity with the technology and history of the field. The advantage of a standing board is familiarity with patents and procedures. Pick it... Patents and Procedures. [LR:] Be very careful. No attorney who can be deemed to speak on behalf of IETF regarding patents should be there opining IETF's opinion about actual patents. Instead, I recommend that we have an invited (and probably open) selection of other attorneys who are willing to sign up and actually participate as individuals, not representing specific clients and speaking with appropriate liability caveats. For process purposes, however, the IPR Advisory Board can probably be chaired by an IETF patent counsel just to make sure everyone behaves We'll have to see how many brave attorneys are actually willing to participate in the entire IETF community's behalf, but if W3C is an example, we'll find lots of willing attorneys. :-) I wonder -- the IETF has been known to be hostile to lawyers... Anyway -- I think this is a promising suggestion, and not inconsistent with IETF practice or policy. But a fully-fleshed out I-D -- one that addresses the membership and the alternatives -- is probably needed, if only as a matter of form. [LR:] Ah yes, form. :-) Does anyone else volunteer? Do we have a second? I'll participate, but I sure don't have the cycles to write anything, nor am I likely to be at very many IETF meetings for the PAG WG or even the PAG bar bof... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
Michael Dillon wrote: FSF is very well intentioned; don't understand me to say otherwise. That said, I think their view on IPR is pretty extreme - no IPR is acceptable. Perhaps that is their view as an organization, but if the IETF engages with the FSF to get individuals involved in the IPR discussions, I think you will find more flexibility of viewpoint. Yes but their control is narrow so derivatives are freely made. That's not the license everyone wants for their standard but it serves FSF users. So we should do something that allows any type of standard (open use, open-source, proprietary/controlled use) to be done with the same standards development and validation framework. To do that maybe the licensing needs to be rethought... If the IETF chooses to ignore the FSF, I don't think that strategy will work. Which brings us back to the idea that the party managing the standard development effort should define the licensing model rather than the model being uniform to the IETF. Seriously think this through - how about we modify the standards process so that the WIG Development effort selects the specific licensing model for that effort. In fact you may have several efforts implementing the same services side by side, except with separate licensing's. I think that the licensing model should be totally linked to the standard effort so everyone gets what they want... You guys want ultimate control - so take it - move the licensing process into the Project Definition and allow people to select those models already in place or specify something different. This means that the issue of negotiating this goes away and we can get back to more important topics. We also will in one fell swoop open the IETF to totally open-sourced standards models and proprietary ones too. Imagine that - if the licensing model is just moved into the standard itself from the boiler plate housed in the BCP's. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Settlement proposal - Re: Previous consensus on not changing patent policy
Paul Hoffman wrote: At 2:11 PM -0800 2/16/09, Lawrence Rosen wrote: Let's forget the past; I acknowledge we lost that argument then among those few who bothered to hum. Many of us have heard this in various technical working groups when people who didn't get their way come back later. Such reconsiderations, particularly on topics of a non-protocol nature, are rarely embraced. We are humans with limited time and energy and focus. But are the 1,000 or so emails in recent days from the FSF campaign not a loud enough hum to recognize that our IPR policy is out of tune? No, it is a statement that a group of people who are not active in the IETF want us to spend our time and effort to fix a problem they feel that they have. This is not the first such open source campaign either. IETF needs a more sturdy process to deal with IPR issues. Please consider the suggestions now on the table. Where? I see no Internet Draft, nor any significant group of people who have said they are willing to work on the problem. Seriously, if this is a significant issue for this motivated group of people, they can do some research and write one (or probably more) Internet Drafts. The IETF has never been swayed by blitzes of a mailing list asking for us to do someone else's technical work; we should not be swayed by similar blitzes asking us to do their policy work. We are, however, amazingly (and sometime painfully) open to discussing worked-out solutions of either a technical or policy nature. In this case, worked-out means a document that describes the the current solution, the advantages and disadvantages of it, a proposal for a new solution, and a transition plan. You mean solutions which amuse or are acceptable to the parties directly managing the IETF today, rather than to the IETF's victims, err members. --Paul Hoffman, Director --VPN Consortium The IETF needs a licensing irrelevant model for creating interoperability standards for networking models of all types. If fact if people want to create a IETF standard why should anyone here want to stop them except to prevent that protocol from coming to use, which means that the IETF has become a political entity serving to prevent some entities from being able to productize their efforts meaning that the actions of the IETF itself become adversarial to anyone outside of those that the Standards Trolls want to allow through the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Settlement proposal - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Previous consensus on not changing patent policy (Re: References to Redphone's patent)
John Levine wrote: But are the 1,000 or so emails in recent days from the FSF campaign not a loud enough hum to recognize that our IPR policy is out of tune? Are you really saying that all it takes is a mob motivated by an misleading screed to make the IETF change direction? Yes - exactly that. From the sample of the FSF letters I read, many of the people writing didn't know the difference between Redphone and Red Hat, and if as many as two of them had even looked at the draft or IPR disclosure in question, it'd be a lot. The FSF's absolutist position on patents was set in stone 20 years ago. I don't see why we should be impressed if they occasionally throw a handful of pebbles at us. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: Security Assessment of the Transmission Control Protocol (TCP)
Joel Jaeggli wrote: Keith Moore wrote: Marshall Eubanks wrote: If I am reading this correctly the UK Centre for the Protection of National Infrastructure wants the IETF (or some other body) to produce a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the existing vulnerabilities, discusses the possible countermeasures, and analyses their respective effectiveness. It's difficult to imagine that these things could be adequately captured in a static document, for TCP or any other protocol, because new threats and countermeasures continue to be identified decades after the base protocol is well-settled. Maybe something like an expanded version of the RFC Editor's errata pages would be more appropriate? One might imagine an informational document which was routinely obsoleted by future iterations. Unfortunately this isnt new information - the liabilities of IP have been well identified and understood for years like the BGP4 flap as well. What the IETF still seems to fail to grasp is that it is responsible for its actions so its not taking security and the ability to produce reliable evidence of anything over a network transport are key factors and need to be built into any IETF endorsement that is issued in the form of a standard or standards-track effort. I also would suggest that the IETF be willing to support other protocols besides IP based - hell XNS was way more secure than IP is by its very design. Its not that TCP/IP is bad - its just that it wasnt designed as an evidentiary-grade data transport and that is nowadays a real issue. Keeping it tractable is a product of necessarily limiting the scope. I dont think so. Building an analysis scope which is defined to meet the evidence needs today would address this requirement and only need to be updated periodically to meet those changing evidence models. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Simon Josefsson wrote: Jari Arkko jari.ar...@piuha.net writes: Simon, That's not possible because the IETF policies does not permit free software compatible licensing on Internet drafts published by the IETF. ... See RFC 5378: It is also important to note that additional copyright notices are not permitted in IETF Documents except ... ... The IETF copying conditions are not compatible with free software licenses (modification is not allowed), and additional copyright notices are not permitted. The vast majority of free software licenses is built on the concept of copyright notices and requires preserving the copyright notice. I agree that there are problematic case, but I believe I hope everyone realizes this is only the case if the RFC in question has code. Otherwise it really does not matter. Only some RFCs have code. I don't realize that, and completely disagree. Good point Simon - lets amplify on that thought a tad... Whats the difference between the two of these statements? 1 + 1 = 2 and One plus one equals two One is a formula (i.e. code) and the other not? This is the same point I brought out about controls in I-D's and RFC's per se, the code can be in any numbers of forms including actual code (as encoded), pseudo code, or just the written description of that process. All of these form code in one derivative form or another and as such all of them need to be covered. If you want free software authors to publish free standards (as in free software compatible) in the IETF, the IETF needs to allow free software compatible licensing of their work. Right now, the IETF disallow standards published through the IETF to be licensed under a free software compatible license. The only alternative for these authors is to release their work outside of the IETF. This may result in some free software authors doesn't bother publishing their work in the IETF because the licensing models are incompatible. I support experiments in this space, though. And it would be really good to get more of the open source folk participate in IETF specification work. There are many important open source extensions and protocols that fit in IETF's scope but were never documented. Even if source code is freely available, you could have several implementations, commercial vs. open source interoperability issues, etc. I agree. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
LORAN is making a comeback..
Folks because of the problems with GPS the LORAN system and a new location based encrypted LORAN is emerging. But there is an opportunity to expand that and layer PPP or some other rudimentary stack atop the LORAN transport Anyone else interested? Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Simon Josefsson wrote: Jari Arkko jari.ar...@piuha.net writes: Harald, Margaret, and Simon, Harald wrote actually that's intended to be permitted by RFC 5377 section 4.2: and Margaret wrote: However, I don't think that anyone actually believes that the IETF will track down people who copy RFC text into comments and sue them or attempt to get injunctions against them. (2) Even if the IETF did try to sue you for copying sections of RFC text into your source code comments, they'd almost certainly lose So it seems that we actually do have at least some ability to deal with comment-style use of RFCs fragments in free software. Simon, do you see any residual issues that we need to solve, or were your concerns in areas other than comments? The discussion started by Stephan suggesting that free software authors publish their work as free standards in the IETF. My point was that since the IETF disallow publishing standards under a license that is compatible with free software licensing (e.g., allows modification), it is not possible for free software authors to do this. Thus, to me, this discussion is not related to comments in source code at all. So then just create another IETF Standard for Open Source Licensing. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
If you install Mail Filters how is the list integrity to be documented?
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 Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: It's time for some new steps (was: [Welcome to the Ietf-honest mailing list])
Scott Brim wrote: Excerpts from Cullen Jennings on Tue, Feb 10, 2009 09:40:55AM -0700: On Feb 9, 2009, at 6:20 PM, Scott Brim wrote: Dean's mail does not hurt any of us. OK, it does take a minute of our time to unsubscribe but that's it. In my opinion it is not alright for someone to harvest email address off and IETF list then subscribe all those people to some list they did not consent to be on? I see your point, but does it warrant a perpetual irrevocable ban on all interactions? So then you would also ban those company's who use this same tactic. Cisco and many others do use this as a part of spraying their advertisement's all over so unless you want to the GC dispute this as true, then we need to move on PS. I would also like to point out that though Dean may allow Scott to unsubscribe, there are many people that he does not allow to unsubscribe. Are you sure of that? Have you tried? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem
Ed Juskevicius wrote: The IETF Trustees met via telechat on February 5th to decide on some proposed revisions to the Legal Provisions Relating to IETF Documents policy, based on comments received from the community in the last two weeks. Please recall this work is being done to provide a work-around for authors having the 'pre-5378 problem'. The telechat was productive. The Trustees reached consensus to do the following: 1) Clarify the copyright text at the beginning of the BSD license in Section 4.1 to read as follows: Copyright (c) insert year IETF Trust and the persons identified as its authors. All rights reserved. ALL of those owning IP Rights then must also be listed or at the very least this creates a responsibility on the IETF to properly manage those contact addresses in perpetuity. 2) Replace the word and by the word or in one place so that the last sentence of Section 6.c.iii becomes: Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. How would this process be done then? What is the liability and what is the actual process that needs to be put in place to satisfy 'reasonable diligence' in the use of the IETF IP's??? 3) Fix some nits with respect to the inappropriate use of square brackets '[' and ']' in two places. The IETF Trust website has been updated with a new version of the draft Legal Provisions Relating to IETF Documents including the changes described in this message. Please look for the documents dated 2009-02-05 at: http://trustee.ietf.org/policyandprocedures.html . If you have any final comments on this, please post them before the end of February 7th. This is the last call for comments. Regards, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com mailto:edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenarys
Clint Chaplin wrote: On 1/23/09, TSG tglas...@earthlink.net wrote: Contreras, Jorge wrote: Why not just ask them???. All authors have a responsibility to maintain their contact info, otherwise it is easily argued that they abandoned their claims in that IP. Were it to be that simple. Unfortunately, it just doesn't work that way. There are lots of cases in the music industry and in the publishing industry where an author has simply disappeared, and yet copyright still exists. Unless the author can be located, a lot of works cannot be republished, because the copyright owner cannot be found to give permission. You mean under new terms Clint? The IETF still has the rights to republish that work and derivatives under the original submission agreement and that right extends in perpetuity. The problem is that the Trust wants to convert this IP Library to something it can license for money, and this is contrary to all of the RFC2026 submissions. No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.10/1906 - Release Date: 1/21/2009 7:07 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
Contreras, Jorge wrote: No, absolutely not. Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). Jorge - if the contributor's in a RC2026 controlled submission choose NOT to allow the new licensing models, then you are saying that the IETF's new rules apply? If not specifically - which rules would apply. The point is that contracts require that the people being bound by them fully understand the terms and conditions, and if they don't then their gifts are faulty at best. Is this or is it not true - and if not why Counsel Todd Glassey - Original Message - From: ietf-boun...@ietf.org ietf-boun...@ietf.org To: IETF Discussion ietf@ietf.org Sent: Wed Jan 14 19:32:27 2009 Subject: RFC 5378 contributions Hi - I originally asked this question on the WG chairs' list, and was asked to ask again here... The discussion about RFC 5378 (what little I've been able to understand of it, anyway) has focussed on I-Ds and RFCs. However, the definition of contribution in that document includes, among other things, mailing list discussions. Does this mean that we need to get contributor permission before using, for example, material from a pre-5378 RFC in a mailing list discussion, or before including text from a pre-5378 email posting in an internet draft? This seems really silly, but that's what the discussion is starting to sound like to me. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Contreras, Jorge wrote: Just as a simple for example: what is the set of names that needs to be posted just to cover all of the boilerplate text we're required to put in our documents? The boilerplate text is owned by the IETF Trust. No author permissions are needed. Hmm... seems to me that there is a release required for the derivative work here right? Todd Glassey As a slightly harder example: what is the set of names required to cover all the boilerplate text that goes into an RFC containing a MIB module? See above. In addition, MIB modules were licensed broadly under RFC 3978, so they are less problematic than non-code text. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 12/15/2008 5:04 PM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenarys
Contreras, Jorge wrote: Larry - thank you for your contribution! I further want to comment that, as far as I can tell, it may not even be necessary to get *everyone* to sign. Here's the reason: Most RFCs are joint works. Quoting (FWIW) from my own book on the subject of licensing: In the United States, unless they agree otherwise, each of the joint authors may separately license a joint work--and all of its parts--without the consent of any of the other joint authors, and every author must account to the other authors for their share of the profits derived from the license. Consult local law to determine whether one owner of a joint work may license without the consent of the others or must account to the others for his or her licensing revenue. The problem lies with collective works, rather than joint works. Lets identify these then... these are perhaps Publication Desk vs. NoteWell type submissions? In some cases, the multiple authors of IETF documents have each made distinct contributions (i.e., sections or distinct text) rather than i.e. identifiable components of contributions collaborating to produce joint text. Unfortunately it is not possible, in hindight, to determine whether works with multiple authors are joint works or collective works. Why not just ask them???. All authors have a responsibility to maintain their contact info, otherwise it is easily argued that they abandoned their claims in that IP. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 12/15/2008 5:04 PM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
Marshall Eubanks wrote: On Jan 15, 2009, at 9:29 AM, Theodore Tso wrote: On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote: On Jan 15, 2009, at 7:09 AM, John C Klensin wrote: If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the IETF counsel says otherwise, I would just let this one lie. The reason why I do not agree with this reasoning is that these rights are claimed through authorship. If I do not claim authorship in your draft because you use my text, when I have ample opportunity to do so, then I have (in my opinion) effectively lost them, especially in this context (where there is a note well, an assumption of joint contributions, etc.). So it's a problem if every single I-D and RFC author is going to have to consult their own counsel before deciding that won't get into legal trouble when guaranteeing that all of their text is appropriately licensed. This is an IETF list, to discuss matters of relevance to the IETF. Whether or not you need to consult counsel is not really on topic, and for sure you should not make that decision based on what anyone (especially me!) says on this list. If, on the other hand, you do obtain advice of counsel on this matter I would be curious to learn what they say. So whether or not I am I lawyer, and whether or not the Berne Convention very clearly states that copyright rights are automatically enforced, and do not need to be explicitly claimed, and whether or not the Note Well is enough to override the Berne Convention, John's position that he wants to be conservative enough not to make guarantees that might expose him to legal liability is a reasonable one. I don't think it's fair to say, I'm not a lawyer, and you're not a lawyer so you should do something which you fear exposes you to legal risk --- especially when all of the IP training many of us have gotten have basically told us that the Berne Convention explicitly states that you don't have to claim copyright to get copyright protections Yes, I am sure that there are corner cases here, but one thing I have found about legal affairs is that there are always corner cases. No legal matter is ever sewn up 100%, and judges actually do take into consideration when things are done on advise of counsel. We have it, we should use it. Has the IETF Counsel actually given explicit legal advice to all IETF contributors (which would have legal liability implications for the IETF Trust if said advice was wrong, as I understand things) that the Note Well to guarantee the transfer of RFC 5378 rights for text taken from IETF mailing list discussions or at an IETF meeting? Better yet would be if the IETF Trust was willing to ***indemnify*** I-D and RFC authors that they are on firm legal ground for asserting that they have all RFC 5378 rights when they take text from an IETF mailing list discussion or IETF face-to-face meeting, on the basis of the Note Well. After all, it is the IETF Trust which is requiring I-D and RFC authors to make this legal guarantee, so one might assert that in a fair world they should take the legal risks associated with that guarantee. Consider the threat model here. This threat applies ONLY to material that the Trust licenses to third parties (such as, say, the IEEE) for inclusion and modification in their standards. (Just reprinting or translating an RFC is not at issue.) Suppose that you author an RFC today, and use pre-5378 material, and warrant (in good faith) that the Trust has a license for that material, or apply a legend from the Trust that says that these rights are not obtainable by you, and it happens that the original author of that earlier material disagrees with this license to a third party. Note that these earlier author's (and their companies) agreed to freely use this material in the IETF process (the note well, etc.), and so you have no risk just by publishing the RFC as long as it is not licensed to other parties. The Trust would be the party that would be licensing this material to third parties, so clearly the Trust would be the major party at risk. What is your risk ? There is a theoretical risk that the Trust might sue you. That is one thing that the work-around is intended to remove. There is an actual risk that a third party might sue you and the Trust - specifically, that the original author or their heirs, etc., might sue. They can only do this if there is infringing use, and that would have to be based on a license from the Trust. If the Trust does NOT license your material to third parties, then there is no infringement, no one with standing to sue, and no risk to authors. It may be necessary for the Trust to state that they will not assume
Re: RFC 5378 contributions
John C Klensin wrote: I have to agree with Andrew and Tom. If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense reading of 5378's definition of Contributor means that I have to go back, find that person, and get permission to post that draft today (without a disclaimer), just because, in making the posting, I'm asserting that rights are in place that were not granted when the Contribution was made. Correct. john * I've said this several times before, but neither common sense nor fairness permits the IETF to say RFC 5378 became effective when it was published the first week in November, therefore any comments, contributions or drafts that appeared after that date constitute grants of permission under 5378's rules ... especially in the absence of any specific notice to that effect on relevant mailing lists, the presence of a Note Well in the IETF registration packet that referred to the old rules, etc. Those of us who trust that common sense interpretation (or who have been given legal advice that the odds of a judge accepting an early-November date contrary to that interpretation are fairly small) need to behave as if we cannot assume that Contributions made before late November or early December do not imply permission to use the Contributions under 5378 rules. --On Wednesday, January 14, 2009 22:52 -0500 Andrew Sullivan a...@shinkuro.com wrote: On Wed, Jan 14, 2009 at 08:33:35PM -0500, Contreras, Jorge wrote: No, absolutely not.nbsp; Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). Why is the actual situation of the use relevant? Contribution is defined in section 1a of RFC 5378, and it plainly says that mailing list posting and anything one says at the microphone in any meeting is included in the definition. In section 5.1, RFC 5378 says that, by submitting the Contribution, the Contributor is deemed to have agreed that he/she has obtained the necessary permissions to enter into the agreement allowing the IETF to use the Contribution according to the new rules. So, just because the Contribution doesn't _happen_ to end up in use outside the IETF by virtue of the IETF's actions does not mean that a Contributor doesn't have to obtain the rights to allow such re-use. I believe that the _intent_ of 5378 is ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
Contreras, Jorge wrote: All -- It's been pointed out to me that I may have been answering the wrong question, or at least only a subset of the full question, in my posting of last night, so I'll clarify below in some detail. But first, for those whom I haven't met before, you should know that I'm a lawyer -- the lawyer who has been advising the Trust on these issues. I did help produce the work-around proposal that Ed circulated last week, and am also one of the co-authors of RFC 5378, so I take some of the blame for starting this whole mess in the first place. This being said, I'm not putting forward an official position of the Trust, nor has the below message been vetted by the Trust. It's simply my attempt to clarify my earlier response, which someone (not a Trustee) suggested that I send. 1. It's correct that Contribution, as defined in RFC 5378, includes e-mail exchanges, oral discussions and any other contribution to the IETF process. This definition has existed since RFC 3978 and the Note Well that has been published for the past several years. 5378 did not make a change here. Unfortunately that means that participation from anyone who's corporate policy is that the corporation owns the IP moving through their email gateway makes the individuals assertion of those rights subject to that oversight and as such the conveyance model is flawed and ineffective. 2. Therefor, the same rules that apply to I-D submission also apply to the other, less formal, types of contributions. John and others are correct in drawing this conclusion. yeah, but only because the IETF's process makes criminals out of those who fraudulently assert they have and continue to have power of attorney for their sponsors when in fact most all of them don't. 3. The IETF (meaning the collective activity of participants who interact on standards-development activities under the aegis of the IETF) has a perpetual, irrevocable right to use all Contributions in the IETF Standards Process. The scope of that changed and the actual terminology changed with these documents and since the IETF refused to force its submitters to prove that they actually do own those rights when 99% of the corporate sponsors have formally filed notices with their SOX compliance processes that there are no external contracts which effect their employees and no external contracts which effect their IP operations. This right applies to all IETF Contributions, whether made under the rules in existence under 5378, 3978, 2026 or earlier. That was my response to Randy Presuhn last evening. Hmmm... ONLY if the party submitting that IP has the legal authority to convey its ownership or to license it to the IETF. If the party working within the IETF doesnt have those rights then the IETF becomes a co-conspirator after the fact to a RICO violation one would think. 4. However, various people have identified a bug in 5378 that relates to hybrid Contributions -- those that contain both pre-5378 and post-5378 material. In short, contributors can't assure the Trust that pre-5378 contributions meet all the requirements of 5378. The same is true of revisions to existing documents when the submission conveyance process changed too. 5. The Trust's proposed work-around deals with this issue by allowing Contributors to flag hybrid contributions. If the flag is in place, then licenses outside the IETF Standards Process are not allowed, and the set of rights being granted for the pre-5378 and post-5378 material becomes equivalent (i.e., full use within the IETF Standards Process, plus a couple of other rights for code, etc.) As a result, if the flag is in place for a Contribution, the Contributor can make the warranties required by 5378 without worrying about any violation with respect to the included pre-5378 material. Again - this doesn't make sense to me. Pre-licensed works are still licensed under those terms whether the IETF changes those participation rules or not. 6. While this flagging approach seems to be workable (from what I've heard) for I-Ds and other formal contributions, it would not be easy to manage for less formal contributions, such as e-mails and especially oral statements. That's the issue that John, Theodore and others have been elaborating recently, and I do agree. 7. Unfortunately, the Trust's ability to affect 5378 is limited to the inclusion (and tweaking) of the legends that are included in I-Ds and other written documents. 5378 does not give the Trust a broader power to alter the rights granted under 5378 or the warranties required by 5378. Thus, the proposed workaround, with the flag applied to submitted I-Ds, is probably as far as the Trust can go at this point (though I'm open to suggestions). 8. Ultimately, a fix is needed to 5378. But, in the interim, I was hoping that the proposed work-around would enable *most* IETF work to continue, and also hope that, while technically correct, the
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
Russ Housley wrote: Russ the phrase COUNSEL reviewed the text is meaningless from a legal standpoint without specifically asking particular questions. So what is it exactly that the Counsel reviewed and is willing to issue a formal opinion on? Todd Glassey John: I think that the cover note from the Chair of the IETF Trust, Ed Juskevicius, included the vast bulk of the information that you are requesting. Russ, I think your note addresses several more of the issues I was concerned about than Ed's note did. Assuming that your note represents the consensus of the Trustees where that is relevant, I don't see any reason to quibble about that point. More to the point, while I think I disagree with parts of your analysis, the disagreements, if any, are in areas that should not block progress at this point, i.e., I can live with your interpretation without any need to dispute those differences. I do have a comment on (3) in context... (3) with the advice of Counsel, we believe that this fix represents a competent, best-efforts, legal-text representation of that principle and nothing else. The cover note does not address all of these points. The Trustees did seek legal advice, and Counsel fully support this work-around. As you might imagine, Counsel was heavily involved in the discussions as well as the words themselves. The Trustees are trying to provide a near-term work-around within the current BCPs and nothing else. Good. However, what I was looking for was assurance from Counsel that he had done an in-depth analysis of the language and concluded that it was both necessary and sufficient to address and solve (or work around) the problem. That is different from supporting the work-around, involved in the discussions, etc. Ekr's recent note points out part of the problem that I believe that Counsel should have caught (and would have caught if asked the right question). The intent, as ekr and I understand it and as I think your and Ed's note indicated, was to eliminate the requirement that authors make any assertions at all about work other than their own, much less requiring that they guarantee those assertions. Perhaps, for a document some of whose text predates 5378, I am certain about the origins of all of the text and can make assertions about it and about whether or not everyone has signed off. But, if I am not, I should not be required to make assertions, one way or the other, that require that I claim and take responsibility for, complete knowledge. Even if I am willing to take responsibility for identify all of the relevant Contributors, unless there is a compelling reason that I haven't heard yet, we should not be requiring authors to search the Trust's archives to determine who has signed off, who has not, and whether the statements they made in signing off are sufficient to meet the conditions of 5378 as modified by the workaround. So I strongly support the general thrust of ekr's proposed modified text rather than the text as posted. If a change is made that is consistent with the general principle that authors who know that they are working on documents that contain pre-5378 text, text about which others might make claims, do not need to make any affirmative assertions at all about the IPR status of that other work. Counsel certainly reviewed the text, but like many groups, there was input from several individuals coming in at roughly the same time. One of the portions the text that EKR is concerned about resulted from edits that I suggested. I do not agree with some aspects of his interpretation, but that is not important because I think his suggested words are even better. This is the point of the community review. I'm pleased to support them. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Disappointing communication
John C Licensing wrote: Larry, You sent me an off-list note on this subject last night, at around 9:30PM my time. When last I checked, this was a weekend and some of us do not spent all of weekend evenings reading and responding to email. When your note caught up with me, it was even later at night. I started working on a careful response at that time. I believed that it should be careful because I have gradually learned that, when an email exchange already shows evidence of miscommunication and especially when issues that are not engineering-technical are involved, it is wise to take some time to write and then to review what is being said before sending the note. I've spent the last few hours trying to remove a recent snowstorm in spite of a back that has gone tricky on me, came back in, did one more review of that note, and sent it. You should have it in hand by now. I then checked the IETF list and found the note quoted in part below. I do not consider failure to respond to you instantly, especially on a weekend, to be a major breach of responsible or reasonable behavior, even if I'm responding to notes that take less careful consideration in the interim. It was inappropriate for ANYONE to take any of the list's business off list, and personally, the fact that the party who did this was a lawyer is also serious. Any and all communications that pertain to the IETF *** must *** by the sheer definition be open and as such need to be a part of the IETF's record process. This is not the first time I have raised this complaint before and its equally appropriate here. As I hope will be very clear when you read that off-list response, you misunderstood both what I was saying and the point I was trying to make. I do believe that there is a problem with how you, as an attorney giving informed legal advice but also trying to advocate for particular outcomes, are interacting with this list. As do I... I do not believe it is an ethical problem and certainly did not mean to imply that your clients were other than good ones. I will say its an ethical issue. I believe that the style is helping to obscure the issues here, rather than clarifying them and bringing us closer to mutual general understanding and, I hope, consensus. You are certainly entitled to disagree with that opinion, but I hope the off-list note will at least bring us closer to a mutual understanding. One thing I did not say in the off-list note, but perhaps should have, is that I get even more irritated with people who pose as researchers, giving balanced presentations of data and options, but who are actually slanting or censoring information to forcefully advocate a particular point of view. This could be used to describe many of the IETF's own WG's and their member's especially the IPR workgroup in my opinion. It is not an attorneys versus the rest of us issue (much less you versus me) but one of styles that I believe bring communities closer to collective understanding and informed consensus rather than styles that are appropriate when the goal is to influence a third party whose job it is to pass judgment. Garbage. Its about a bunch of technologists who want to believe they are above the law and that the law is something that will conform to their will because they are 'chartered by themselves' to be the protector's of the Internet. What a crock of BS... If, after you reread my hastily-written on-list earlier notes, you conclude that their content contributed to your misunderstanding of my intent, I apologize for the haste of writing and that misunderstanding. If, after reading both this note and that one, you think you are still due a public apology, please say so. While my off-list note is one of those long analytical pieces that several participants in the IETF hate to see, much less read, I don't consider anything in it to be either private or secret, so feel free to post it to this list if, for some reason, it makes you feel even more aggrieved (and understand that I may do so if this conversation needs to continue and I conclude that it would inform the conversation -- that is not a threat in any way, I'm just trying to avoid cluttering the IETF list discussions any further). regards, john --On Sunday, January 11, 2009 10:26 -0800 Lawrence Rosen lro...@rosenlaw.com wrote: ... Why are such emails tolerated on IETF's discussion list? I have participated on IETF lists for several years now, trying hard to respect IETF's culture and norms for civil communication. I learned early on that everyone in IETF perceives his or her role as an individual serving in the best interests of the technologies we jointly need. While none of us can fully leave our hats at the door, we are expected to represent what is best for the Internet. ... I believe I deserve an apology from John, although that may be too much for a lawyer to ask. ___ Ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Lawrence Rosen wrote: John Leslie wrote: I may not be the one to explain, but I _don't_ think that's what the proposal calls for. I think it calls for inclusion of the boilerplate I listed above, which simply disclaims knowledge of _whether_ all the rights of 5378 are granted (and thus derivative works outside the IETF Standards Process are not authorized by the IETF Trust). I want derivative works outside the IETF Standards Process to be authorized by the IETF Trust and see no legal reason, at least in US law, why the IETF Trust can't authorize that without even mentioning the co-authors of those RFCs. The concern expressed in this thread is whether derivative works are authorized by the co-authors of those earlier RFCs. We need no statement (admission of guilt or otherwise) about that. Users of IETF RFCs should be comfortable that at least the IETF Trust authorizes such derivative works. Which there are serious concerns about whether the Trust ever owned that IP. I.e. that the transfer of the IP to the Trust is permanently flawed by the derivatively requirement's that all derivative works be licensed under the same rights requirements' are the originals are. Certainly the term open industry standard must mean that an RFC is a cooperative expressive and technical work by individuals and companies interested in a common result. But the RFC is not an open license to use the IP for any and all purposes, i.e. that beyond publishing written copies of those IP's that the content can be used to create other IP's like Software Systems which implement that standard. We should accept the notion that IETF, and now the IETF Trust, as a public interest corporation that manages the expressive creative activities through which these joint works are written, is the joint owner of copyright in every RFC. No we shouldn't Counsel. The Trust DOES NOT OWN ANYTHING that was licensed under RFC2026 unless a separate contract was executed by those authors authorizes that change in the original licensing. The problem is that *** ANY *** derivative work which is done under a later filing but also includes component's or technology from one of those earlier filings those new filings must also track that earlier licensing. As such, a license from the IETF Trust is all we need to create derivative works, without even asking the co-authors of those old (or new) documents. I disagree. Does anyone here believe that the IETF Trust doesn't own a joint copyright interest in every RFC it publishes and can thus authorize derivative works of those RFCs? [1] yes. /Larry [1] I intentionally avoid the argument, made in my previous emails here, that we don't even need the permission of the IETF Trust to copy and modify--when necessary for functional purposes--any industry standard specification. That's a bigger argument based on 17 USC 102(b), not one based on the Copyright Act definition of joint work: A 'joint work' is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole. 17 USC 101. Lawrence Rosen Rosenlaw Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John Leslie Sent: Friday, January 09, 2009 10:15 AM To: dcroc...@bbiw.net Cc: IETF Discussion Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem Dave CROCKER d...@dcrocker.net wrote: A number of the comments, so far, appear to hinge on a rather basic cost/benefit model that is clearly quite different from what the proposal is based. I suspect that difference comes from a different sense of the problem, per John Klensin's posting. Agreed. My reference to legality is based on a view of the proposal which sees it as having individual submitters essentially say I am required to get permission and I have not gotten it. That's an admission of guilt... I don't read it that way. Refer to: http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions- 1-06-09.pdf ] ] 6. c. iii. ] ... This document contains material from IETF Documents or IETF ] Contributions published before November 10, 2008 and, to the ] Contributor's knowledge, the person(s) controlling the copyright ] in such material have not granted the IETF Trust the right to allow ] modifications of such material outside the IETF Standards Process. ] Without obtaining an adequate license from the person(s) controlling ] the copyright, this document may not be modified outside the IETF ] Standards Process, and derivative works of it may not be created ] outside the IETF Standards Process, except to format it
Re: [mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header
Douglas Otis wrote: On Jan 9, 2009, at 12:48 PM, Lisa Dusseault wrote: Hi Doug, Does anybody support your review of sender-auth-header, to the point of believing that the document should not be published? So far you are still very much in the rough part of rough consensus. thanks, Lisa On Wed, Jan 7, 2009 at 1:14 PM, Douglas Otis do...@mail-abuse.org wrote: Murray, There has been progress, but a few extremely critical security related areas still need to be addressed. I have posted a draft that reviews the sender-auth-header draft. The text and html versions are available at: http://www.ietf.org/internet-drafts/draft-otis-auth-header-sec-issues-00.txt http://www.sonic.net/~dougotis/id/draft-otis-auth-header-sec-issues-00.html Funny that you describe your concern as involving rough consensus. The draft itself can't decide when it should stop pretending about what defines authentication, and remains remains contradictory on this critical subject. It states that only _authenticated_ information should be included within the Authentication-Results header for either Sender-ID or SPF. At the same time, the draft defines Sender-ID and SPF as being an authorization method and _not_ the authentication of the domain. In fact, there is no way to know whether Sender-ID results were based upon SPF version 1 records in its current form, or whether a domain even intended positive results to affirm its identities, or whether just negative results of a Mail From were intended to mitigate back-scatter. This leaves the issue of authentication itself clearly in the rough. In addition, there is also the matter of encouraging the use of dangerous local-part macros when one wishes to obtain email-address annotations. At least the Sender-ID specification states local-parts are _not_ verified. What is providing the authorization remains unknown for SPF, even though the local-part is ignored in Sender-ID. In addition, there is no consensus between either Sender-ID or SPF as to which elements of a message are to be used to access version 1 records. Clearly, scoping issues are also in the rough. Nevertheless, this header is willing to label results of this mess Authentication-Results. I suggest that the Technological sense of Authentication is irrelevant here. The real issue is what the Court's and those stuck using these protocols are forced to do to prove their actions. As such its the Court's Authentication Schema's that should be relied on here rather than what we as technologists would prefer. The remedy being sought is to replace the local-part of the authorizing email-address with a converted string representing the IP address of the SMTP client that is being authorized. This allows the authenticated origin of a message to be vetted, in addition to what _might_ be an authorizing domain. A fair compromise. Except that there is no way with the proposed model to prove that IP address is accurate and not being spoofed. While there are influential proponents of this draft, this draft and the experimental SPF and Sender-ID RFCs remain dangerous as written. With a few minor modifications, the Authentication-Header draft would become much safer. Satisfying those that represent influential special interests should not cause the IETF to dismiss their stewardship role. The IETF is a steward of nothing. Its a Standards Platform and management process to create 'open and fair' internet standards. We all know there is money to made picking up the pieces, but there are more productive ways to make a living. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS/IP
Toni Stoev wrote: Hi, DNS job When a connection to a network node is to be initiated its DNS name is resolved to an IP address which shows the location of the node on the network. So network nodes are findable by name even if their locations change. I think you are backwards... The nodes are still reachable if they change their physical location or the assigned networks addresses temporarily mapped too those names by DNS or DHCP. The job of the DNS is to identify a node by its name. Another job is to maintain information about node's current location so a new connection can be started at any time. Hmm... I think the job of DNS is to map the 'text based system names' to a network address that the routing infrastructure and features can create a set of pathways for that data to reach said system. Why should DNS be bothered with connectivity and/or topology status? There must be a distinct mechanism to handle mapping of node identity to network location. GeoPriv would have you believe that another ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
Ed Juskevicius wrote: Ed - you nor the rest of this list is going to like this retort but I would ask that you read all of it prior to flushing the response. The purpose of this message is twofold: 1) To summarize the issues that some members of our community have experienced since the publication of RFC 5378 in November 2008, and 2) To invite community review and discussion on a potential work-around being considered by the IETF Trustees. Some I-D authors are having difficulty implementing RFC 5378. An example of the difficulty is as follows: - an author wants to include pre-5378 content in a new submission or contribution to the IETF, but - s/he is not certain that all of the author(s) of the earlier material have agreed to license it to the IETF Trust according to RFC 5378. Then the submission of such an assertion would be a criminal act of fraud by wire... and that is not a joke. If an I-D author includes pre-5378 material in a new document, then s/he must represent or warrant that all of the authors who created the pre-5378 material have granted rights for that material to the IETF Trust. Something which by the way is physically impossible because of how the RFC2026 licensing model was setup. Hell even BCP78 and 79 exist under RFC2026 rules since they had to be published as such to get them into the channel to review and advance them to the BCP's. As such these all are moot... funny that eh? If s/he cannot make this assertion, then s/he has a problem. This situation has halted the progression of some Internet-Drafts and interrupted the publication of some RFCs. The Trustees of the IETF Trust are investigating ways to implement a temporary work-around so that IETF work can continue to progress. A permanent solution to this pre-5378 problem may require an update to RFC 5378, for example new work by the community to create a 5378-bis document. You mean a POST-5378 IP Disclosure Document. The issue is what happens to any derivative licensing which stems from RFC2026 based controls. And since 5378 is a derivative of the BCP78 document it is tied itself to the RFC2026 rules still too one could easily argue. The remainder of this message provides an outline of the temporary work- around being considered by the Trustees. RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the authority to develop legend text for authors to use in situations where they wish to limit the granting of rights to modify and prepare derivatives of the documents they submit. The Trustees used this authority in 2008 to develop and adopt the current Legal Provisions Relating to IETF Documents which are posted at: http://trustee.ietf.org/license-info/. RFC2026 will not allow this. In fact once published under RFC2026 those document's are cast in concrete as far as the license model is concerned. The Trustees are now considering the creation of optional new legend text which could be used by authors experiencing the pre-5378 problem. The new legend text, if implemented, would do the following: a. Provide Authors and Contributors with a way to identify (to the IETF Trust) that their contributions contain material from pre-5378 documents for which RFC 5378 rights to modify the material outside the IETF standards process may not have been granted, and Meaning that those documents would be published under yet another set of IP licensing constraints - So lets see that makes 1) Pre BCP78 o- Pure RFC2026 based licensing 2) Post BCP-78 publishing with Pre-BCP 78 licensing included o- Includes non-trust managed IP o- Includes trust managed IP 3) Post BCP-78 with pure BCP-78 licensing through the Trust b. Provide the IETF Trust and the community with a clear indication of every document containing pre-5378 content and having the pre-5378 problem. Ahahahah - Oh damn that's funny. Try all of the RFC's published prior to (IMHO) the IESG's #$%^*()_ act of putting BCP78 and BCP79 into production. So, how could the creation and use of some new legend text help people work-around the pre-5378 problem? It cannot. The RFC2026 Licensing model clearly must survive the original filing of the original BCP78 and its ludicrously funny and pretty stupid brother BCP79. The proposed answer is as follows: 1. Anyone having a contribution with the pre-5378 problem should add new legend text to the contribution, to clearly flag that it includes pre-5378 material for which all of the rights needed under RFC 5378 may not have been granted, and They, according to the IETF submission process, cannot do this because the amended document supposedly has to be submitted under the BCP78/79 Terms which is what we are saying doesn't work here. So this is clearly impossible. 2. The IETF Trust will consider authors and contributors (with the pre-5378
Re: RFC 5378 Contributor License Form
Ray Pelletier wrote: All What does that mean to the contractual relationship to the IETF's process for those IP's being evoplved inside it? Seems to me that place a stop on anything places a stop on everything. Todd The trustees are aware of the problems with respect to the RFC 5378 implementation and possible consequences with respect to the license. Pending a further analysis, and possible modification to the license, we have taken the current license off-line. You may also expect a proposal for a temporary workaround to the problems identified by the implementation of RFC 5378. That proposal is currently reviewed by the trust and will be posted as an Internet Draft soon. Ray Pelletier IAD/Trustee ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 12/15/2008 5:04 PM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
Hallam-Baker, Phillip wrote: It depends on what level you are looking at the problem from In my opinion, application layer systems should not make assumptions that have functional (as opposed to performance) implications on the inner semantics of IP addresses. From the functionality point of view an IP address should be considered by the application to be no more than an opaque identifier. The reason for that is precisely to allow the routing layer to make architectural decisions that do apply semantics to the address and which change over periods of time that are relevant to routing layer deployment cycles (there are plenty of pre-1995 Internet hosts still in service, I will wager a rather smaller percentage of backbone routers from 1995 are still in service :-). Which is why I want to see ad-hoc semantics that applications attempt to apply to IP addresses being replaced by DNS level (ie reverse DNS) facilities that achieve the same effect in a fashion that does not result in applications breaking if those assumptions are broken. On the geographic nature of IP addresses, clearly some level of aggregation is essential but it is equally clear that 100% clean aggregation is never going to be achievable either. The longer a block is in service the more it gets 'bashed about'. Entropy increases. Only if they are used as reliable network monuments. And yes that is the proper term for it and one we should start using as a particular form of trust anchor. When we did the Controlling access patent, this was part of the control and reporting model we built for it. At the moment the Internet architecture has a built in assumption that the system is going to grow. And that keeps the chaos factor in check because the new blocks are a significant proportion of the whole and have nice regular assignments at issue. But what when the system stops growing? How do we keep the chaos to an acceptable fraction? This leads me to consider an IP address block assignment as being an inherently term limited affair, with the sole exception being root DNS where perpetual assignments are going to be necessary. The terms need to be long, years, probably decades at minimum. But there needs to be a built in assumption that over time there will be a 'recycling' of broken down, atomized address blocks into larger clumps that aggregate nicely. Which in turn is only possible if nobody (apart from core DNS) cares about their IP address having a specific value. -Original Message- From: ietf-boun...@ietf.org on behalf of Bryan Ford Sent: Wed 12/24/2008 1:50 PM To: macbroadcast Cc: ietf@ietf.org Subject: Re: The internet architecture On Dec 22, 2008, at 10:51 PM, macbroadcast wrote: IP does not presume hierarchical addresses and worked quite well without it for nearly 20 years. IP addresses are topologically independent. Although since CIDR, there has been an attempt to make them align with aspects of the graph. Ford's paper does not really get to the fundamentals of the problem. I would suggest that deeper thought is required. would like to know bryans opinion I think I missed some intermediate messages in this discussion thread, but I'll try. :) IP addresses are just an address format (two, actually, one for IPv4 and another for IPv6); their usefulness and effectiveness depends on exactly how they are assigned and used. CIDR prescribes a way to assign and use IP addresses that in theory facilitates aggregation of route table entries to make the network scalable, _IF_ those addresses are assigned in a hierarchical fashion that directly corresponds to the network's topology, which must also be strictly hierarchical in order for that aggregation to be possible. That is, if an edge network has only one upstream provider and uses in its network only IP addresses handed out from that provider's block, then nobody else in the Internet needs to have a routing table entry for that particular edge network; only for the provider. But that whole model breaks down as soon as that edge network wants (god forbid!) a bit of reliability by having two redundant links to two different upstream providers - i.e., the multihoming problem, and hence all the concern over the fact that BGP routing tables are ballooning out of control because _everybody_ wants to be multihomed and thus wants their own public, non-aggregable IP address range, thus completely defeating the scalability goals of CIDR. For some nice theoretical and practical analysis indicating that any hierarchical CIDR-like addressing scheme is fundamentally a poor match to a well-connected network topology like that of the Internet, see Krioukov et al., On Compact Routing for the Internet, CCR '07. They also cast some pretty dark clouds over some alternative schemes as well, but that's another story. :) But to get back to the original issue, CIDR-based IP addressing isn't scalable unless the
Re: where to send RFC 5378 license forms
macbroadcast wrote: There are also numerous Federal Co-Development programs in the various Excutive Branch agencies and they also must be included here because those may also have outside privte commitments as well. Todd Glassey federal works sorry for my might be oftopic comment, so if i see something like this in a source code, , This material is partially based on work sponsored by the National Science foundation under Cooperative Agreement No NCR-x.The Government has certain rights in this material. --- this would encumber me from using it, if i understand it correctly, so i thing you really need to be careful when you get sposorship for an open source project for example. just my 2 cents best regards marc Also do not forget that the US Government does not claim copyright. Were any RFCs written by US Civil Servants ? Then their work is in the Public Domain. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 12/15/2008 5:04 PM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Russ Housley wrote: Marshall: My understanding (and IANAL and Jorge is welcome to correct me) is that the IETF does indeed have sufficient rights to allow re-use of IETF documents within the IETF, and that this is purely concerned with the power of granting modification rights to other parties. This is not a very common occurrence as far as I can tell, and so in some sense this is a corner case. You are correct that the rights for the IETF Standards Process are already in place, at least for every contribution made after RFC 2026 was published. However, RFC 5378 does not include a provision for a contribution that does not grant all of the required rights. Even if the IETF Trust were to never make use of any rights beyond the IETF Standards Process, these additional rights must be granted under the requirements of RFC 5378. If a person cannot obtain the necessary rights, then that person cannot make a contribution to the IETF. This was the consensus of the IPR WG and the IETF, and the IETF is now operating under the resulting process BCP. Russ Which changes the IETF from arguably a pure RD NPO to a IP Licensing House with a portfolio worth at the very least the hundreds of millions spent on producing it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.16/1840 - Release Date: 12/9/2008 4:53 PM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-geopriv-http-location-delivery-07
FYI - the IETF IPR disclosure process doesn't work very well since GEOPRIV directly violates our patent - see IPR notice #201. Todd Glassey - Original Message - From: Eric Rescorla [EMAIL PROTECTED] To: Mary Barnes [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Sent: Friday, June 20, 2008 11:59 AM Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07 At Thu, 29 May 2008 07:51:02 -0500, Mary Barnes wrote: Hi Eric, Thanks for you review and comments. My responses are embedded below [MB]. Mary. -Original Message- From: Eric Rescorla [mailto:[EMAIL PROTECTED] Sent: Saturday, May 24, 2008 9:01 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Review of draft-ietf-geopriv-http-location-delivery-07 $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 15:03:19 ekr Exp $ TECHNICAL S 4.2. which a Location Recipient (LR) can use to retrieve LI. A location URI provided by a LIS can be assumed to be globally-addressable; that is, anyone in possession of the URI can access the LIS. However, this does not in any way suggest that the LIS is bound to reveal the location associated with the location URI. This issue is deemed out I don't understand this point. anyone in possession of the URI can access the URI but the LIS isn't required to reveal it? Those seem kind of contradictory. [MB] Your comment is similar to a point made by Ben Campbell's gen-art review. The text is unclear, in particular the However, clause. The changes agreed as a result of the gen-art thread http://www.ietf.org/mail-archive/web/gen-art/current/msg02995.html are reflected below (also incorporating another issue Ben raised, as well, by adding a new paragraph to that section): NEW: However, this does not in any way suggest that the LIS indiscriminately reveals the location associated with the location URI. The specific requirements associated with the dereference of the location are specified in [I-D.ietf-geopriv-lbyr-requirements]. The location dereference protocol details are out of scope of this document and are specified in [I-D.winterbottom-geopriv-location-deref]. It should also be noted that while the lybr requirements document specifies a requirement that a client SHOULD be able to cancel location references, the protocol specified in this document does not provide that functionality. The mechanism to provide this support in the protocol requires explicit management of Target state on the LIS. It is anticipated that extensions to HELD may support that requirement. Does the revised text help to alleviate your concern? Well, it alleviates my concern about the security question, but it reinforces my concern about the completeness of this specification. Unless I'm missing something, this is a major normative dependency on draft-winterbottom-geopriv-location-deref? I'm not sure we can assess this protocoal with that reference unbound. It could also be useful for a VPN device to serve as a LIS for other location configuration options such as Dynamic Host Configuration Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED) [27]. VPN devices that serve as a LIS may acquire their own location using HELD. Yes, I think this is an improvement. S 5.1. o The HELD protocol must provide authentication, confidentiality and protection against modification per Section 10.3. Are you talking about HELD, which doesn't seem to have these features, or about the transport protocol? Also, authentication for who? Based on what model? [MB] Per your subsequent response to Hannes on this point, I will change that bullet to read: o The HELD protocol REQUIRES that the underlying transport provide authentication, confidentiality and protection against modification per Section 10.3. Agreed. S 6.5. I'm having trouble keeping straight two kinds of URIs: - URIs that a Device uses to get its own LI. - LbyR references that the LIS hands out. This text seems to imply that an LIS can hand out a helds: URI. Is that *also* the URI that a Device derferences? [MB] Yes, the helds: URI that a device receives in a locationResponse is the URI that a device would dereference. But, it's important to note that the LIS does not have to return a helds: URI - other URIs may also be used per the text in section 6.5. [/MB] Hmm... Then I think this needs some explanation in the main text. S 6.5.1. A locationURI SHOULD NOT contain any information that could be used to identify the Device or Target. Thus, it is RECOMMENDED that the locationURI element contain a public address for the LIS and an anonymous identifier, such as a local identifier or unlinked pseudonym. 1. This seems like it should be clearer about what is desired. In particular
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Uh, Folks DOMAIN NAMES cannot be reserved in that manner and this lawsuit from the US District Court says so. http://www.domainnamenews.com/wp-content/uploads/2008/06/express-media-express-corp-nd-ca.pdf That's not going to fly. DOMAIN NAMES are IP and need to be registered as TM's to protect them. If you want these domains to be protected and reserved then register them and pay the filing and maintenance fees on them. Todd Glassey - Original Message - From: Robert Elz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, June 17, 2008 10:49 AM Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis Date:Tue, 17 Jun 2008 15:50:02 +0100 From:Debbie Garside [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | I would also add that to go against an IETF BCP Huh? The BCP in question says (in a bit more eloquent form) Here are some domain names that are reserved from all normal use, and so are suitable for use in places where something with the syntax of a valid domain names is required, but no real domain name should be used - use them where applicable. It does not say you must use these domain names (for any purpose at all). Where's the go against an IETF BCP here? kre ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
FYI - ALL of the commentary submitted to the IESG must be done so through a process which includes it in the archive of that IP initiative or the IETF will see itself in a world of hurt the first time it is litigated against and it cannot produce documentation showing all of that material happened in the open. Todd Glassey - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: John C Klensin [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Sent: Sunday, June 15, 2008 5:23 PM Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis Dave, On 2008-06-16 11:44, Dave Crocker wrote: Brian E Carpenter wrote: I think one can make a case that in some documents, use of non-RFC2606 names as examples is a purely stylistic matter, and that in others, it would potentially cause technical confusion. I'm not asserting which applies to 2821bis, but I do assert that there is scope here for a judgement call and therefore the inconsistency is understandable. Actually, Brian, scope is exactly what this judgment call is out of. The underlying question is whether rules matter in the IETF or whether the IETF is subject to whatever ADs feel like declaring at the moment. I doubt if anyone would disagree. If rules do matter, then the IESG needs to follow them. In very concrete terms, the IESG needs to be constrained it its application of a Discuss to matters of serious import and to document the basis for an application of a Discuss. Which, in fairness, the IESG has documented, in the DISCUSS criteria document and generally in practice, over the last several years. The question surely is whether the IESG failed to do so in this case. The current case has an AD asserting a Discuss by claiming a rule that does not exist. That's not judgment call, that's invention. I haven't seen all the email in this case, so I don't know exactly what has and hasn't been claimed as a rule. However, I'm arguing that there is scope on this particular point for concluding that there is a *technical* issue (a source of confusion, i.e. a lack of clarity). That may or may not be a valid conclusion. However, one of the two DISCUSS comments points out that at least 3 of the domains used are real ones. So the issue of confusion is a real one. What I am saying is: these DISCUSSes are about a technical issue. They may or may not be reasonable, but I object to the suggestion that they are stylistic or editorial (which would automatically make them out of scope under the IESG's own document). Even better is that application of this invented rule on a revision to an established standard represents an orientation towards change that is de-stabliling rather than helpful. I don't think that changing foo.com to foo.example.com would destabilise the email system too much. Brian With that combination, you can't get much more out of scope. d/ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
- Original Message - From: Robert Elz [EMAIL PROTECTED] To: Brian E Carpenter [EMAIL PROTECTED] Cc: John C Klensin [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 16, 2008 12:51 AM Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis Date:Mon, 16 Jun 2008 13:23:28 +1200 From:Brian E Carpenter [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Which, in fairness, the IESG has documented, in the DISCUSS criteria | document and generally in practice, over the last several years. The IESG is free to document their own procedures, that's a good thing. No they are NOT. The IESG's processes MUST also be transparent just like the IETF's or they risk creating liability for their sponsor's that NONE of those sponsor's will be too happy with. They're not free to invent rules for the IETF, that's for the IETF as a whole. What gets a document approved is IETF rough consensus, that's been the IETF rule for years. If there's any real question whether this revision has IETF consensus or not, then it should be blocked. If there's no question as to that, then it should be approved - after all, the IETF would (under that assumption) have approved it, along with all of its examples. If the example domain names were really an issue to anyone, that would have been raised during last call. At that point, whether or not rough consensus existed to continue with the doc as it was could have been judged. Even if we had a rule that all domain names in RFCs must be from the reserved set (which we do not) the IETF has the power to change its rules. That can be done in general, or on a case by case basis. Raising the issue during last call, and having the IETF decide to ignore the problem for the doc in question would be all that is required to set aside the rule for that doc. But we have no such rule, there's never been a last call on anything that says that all domain names in examples in RFCs must be from the set documented in 2606, so the issue should not even arise. If there ever were such a last call, you can expect I'd be an vociferous opponent, as rules like that make no sense at all. There are perfectly good reasons for those domains to exist, and very definitely places where they should be used, but this is not one of those cases. | I don't think that changing foo.com to foo.example.com would | destabilise the email system too much. Of course it wouldn't break e-mail, but it would make following the RFC sequence, and working out what changed, and why, much more difficult. Further, when dealing with something which necessarily deals (or should) deal with many different domain names (like e-mail does), constraining the examples to be from just a small set or (seemingly relayed) names would do a disservice. Sure, you and I know that the example in foo.example.com is meant to be ignored, and isn't there for any particular purpose, but can you expect that every reader of the doc will understand that. Even if there was an only those domain names rule, and there was a good reason for having that (neither of which is actually the case), there would be a good case for ignoring it for this one doc. If the real domain names used in this doc are a problem to the owners of the domains, I have no real doubt but they would be changed upon request, so that straw-man objection can be ignored. I have no idea which AD has the arrogance to put their own view of what the IETF rules should be above the stated desires of the IETF as a whole (as determined by the last call), but whoever that is really ought to consider resignation as an honourable way out of the mess they're creating. kre ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FYI, more comments on IETF not having members (fwd)
Folks - I don't want to extend Deans rant here because that's between him and you. ...But as to the argument that the IETF has no member's. Sorry, the IETF *** does *** in fact have member's - They are those parties bound under contractual arrangement's with the IETF to participate formally in its processes and who try and avail themselves of the IETF's processes. The joint tenancy in the derivative rights helps to cement that too. In this case under the Open and Fair doctrine the IETF espouses, the definition of member could be as simple as a party trying to avail themselves of the IETF's processes. Todd Glassey - Original Message - From: Dean Anderson [EMAIL PROTECTED] To: TS Glassey [EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 7:53 AM Subject: FYI, more comments on IETF not having members (fwd) FYI -- Forwarded message -- Date: Mon, 9 Jun 2008 13:59:38 -0400 (EDT) From: Dean Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Gervase Markham [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: FYI, more comments on IETF not having members The frivolous, dishonest, and false statements in the January 15, 2008 IESG Appeal Response found at [http://www.ietf.org/IESG/APPEALS/appeal-response-dean-anderson-01-15-2008.txt] must be corrected. Persons are begining to incorrectly claim that the IETF has no members, and no ability to make official statements. In fact numerous Official IETF documents refer to IETF members, and the IETF is part of the Internet Society, Inc, a U.S. non-profit corporation. The ISOC is engaging in improper trade practices by misrepresenting its both its incorporation status and its status as a part of a non-profit membership corporation. Dean Anderson CEO AV8 Internet, Inc -- Forwarded message -- Date: Mon, 9 Jun 2008 10:17:36 -0400 From: Edward Lewis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Gervase Markham [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [DNSOP] Public Suffix List At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote: On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström [EMAIL PROTECTED] wrote: The problem with any such mechanisms is that the barrier of entry for new players (that does not match the currently used list -- including non-upgraded software) is increased. More than what people think. That is why my subtld-structure draft is suggesting that TLD profiles be downloaded at regular intervals (and at need) from a repository, in order to make it possible to add new TLDs or new registry-like domains under a TLD, and to prevent problems with old software. My drafts also suggest a rule-of-thumb fallback in case a TLD is unknown. This thread is going to go around in circles for quite a while. There's a history of the IETF wanting to define something without fixed boundaries. DNS names is one, IPv6 addresses is another. But when it comes to operations, having fixed boundaries makes mass production much easier. E.g., in IPv6, IETFer's (as we know, the IETF doesn't have any official statement source and no members, so I refer to those in the debate that brandish IETF credentials) would say that the days of classful addressing are behind us, so IPv6 addresses ought to be treated as nothing but a string of 128 bits. But RIR policy writers wanted to know whether to recommend /48's, /54's, /32's, etc. for certain types of uses. (Uses not users.) Shifting back to DNS, there's not going to be a scientific differentiation between one zone and another. During the DNSSEC development days we wanted to declare some zones as widely delegated (such as .com) from other zones - to alleviate the issues we see with NSEC, NSEC3, etc. that are apparent still now. There's nothing in DNS to differentiate, at a protocol level, one zone from another, but at the operational end of the stick, there are many differentiators (like whether the administration interface is on paper or via EPP). I doubt that you'll find any repository that can be used to register registry-like zones. The DNS lacks anything like a RADB, RPSL, etc., mechanism employed by the routing infrastructure. Partly because, unlike IP addresses, there is no organizational link through all parts of the Domain administrations. ICANN does not have it's thumbs on all the TLDs - many ccTLDs do not operate under any agreement with ICANN. I admire and respect the effort of web browser implementers to try to improve their code to make it harder to abuse. Even if the desired tactic is on target, it may still fail because the information is just not available. Worse is broken security which will just frustrate the users and make the situation even more fertile for abuse (through uncertainty and confusion). The domain name industry is more complex than one would think. It's not technical, it's
Re: I mentioned once that certain actions of the IETF maybecriminally prosecutable in nature...
Fred - Here is the deal... What I said is that under section (a)(2)(B) of the FEDERAL INTEREST COMPUTER definition section of the CFAA itself, that any two parties involved in any interstate interchange or a single interchange which crosses State borders, is prosecutable under the CFAA, both by individuals as civil matters and then criminally by Federal and State LE... So Email across a state line works just fine for this. What that means to the IETF is simple... 1)The IETF uses a distributed communications system which includes conversations and electronic engineering sessions * (what I will call the vetting process - i.e. that IP which is covered by NoteWell). Many of the participants in this IP generation process are spread out across multiple states and countries. 2)And its worth noting that a)US citizens are constrained by the Foreign Corrupt Practices Act so where ever they are, they are constrained by US law as are others who would periodically enter the US... That means they cannot go to Europe and break those laws or Asia either. It also means that they cannot break those same laws no matter where they are if those servers are located outside of the US Jurisdiction, that's just the law. b)US citizens are also constrained also by the US conspiracy statute and the CFAA no matter where they physically are. Likewise with claims against them under the Stored Communications Act in addition to a couple of others. - Original Message - From: TSG [EMAIL PROTECTED] To: Fred Baker [EMAIL PROTECTED]; Harald Tveit Alvestrand [EMAIL PROTECTED] Cc: IETF Discussion ietf@ietf.org Sent: Monday, June 09, 2008 7:16 PM Subject: Re: I mentioned once that certain actions of the IETF maybecriminally prosecutable in nature... Fred - you are truly funny... - Original Message - From: Fred Baker [EMAIL PROTECTED] To: Harald Tveit Alvestrand [EMAIL PROTECTED] Cc: IETF Discussion ietf@ietf.org Sent: Wednesday, June 04, 2008 9:50 AM Subject: Re: I mentioned once that certain actions of the IETF may becriminally prosecutable in nature... So you're saying that the indictment (which as described does not constitute a conviction and therefore is not case law) is relevant if someone creates an identity for the purpose of deluding others, uses it to inflict emotional distress, and the result is the suicide of a member of the discussion forum - and the bully lives in the City of Dardenne Prairie or more generally the State of Missouri, which have enacted statutes since the girl's death. Is that correct? no Fred - I suggest that per the description of a FEDERAL INTEREST COMPUTER in the US Computer Fraud and Abuse Act, that any instance where IETF member's converse with each other electronically about how they are going prevent anyone else's effort from being submitted, or vetted and advanced, or prevent that person from participating in the IETF through the PR process, that those actions DO constitute criminal and civilly acitonable ones. In your case as an IESG member they also constitute a Fiduciary Responsibility violations too... And so - you know that meeting with Cisco's GC I kept talking about, I am available all next week and since my office is about 5 files down First Street from your legal department this is a no brainer eh? I don't plan to comment further in this thread. In fact, had you and Philip not replied, I would not have been aware of it. To my mind, my stance is a very appropriate one. yes - you are intentionally denying that certain US Laws apply to the IETF's operations and that is simply not true. The IETF is constrained by US law whether its in the US or not based on that all US participants would be tied to the Foreign Corrupt Practices Act. So again, lets ask Mark Chambers what he thinks of this OK???. On Jun 3, 2008, at 9:31 PM, Harald Tveit Alvestrand wrote: --On Monday, June 02, 2008 10:17:16 -0700 TS Glassey [EMAIL PROTECTED] wrote: I brought this up a number of times and Harald's solution was to ban me from the list. Something that under the US CFAA is prosecutable... His claim was that I failed to show him the money - that special case which establishes that as a standard. I believe I told you to show competent legal advice saying that what you were posting was relevant to the IETF. I have read your provided material, and fail to see any sign of such competent legal advice; no name but your own is attached to the claim of relevance. (for those who wonder what case it is, it is http://en.wikipedia.org/wiki/Megan_Meier.) Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF
