Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Dave CROCKER writes: > My assumption was not that the work was "available" for "IETF use". > > My assumption was that the IETF owned the work. Pure and simple. > > The IETF was free to do whatever the hell if felt like with the work > and I retained no rights. Use it. Give it to another group. Kill > it. Whatever. > > Really. That's the cultural basis that I believe formed this > community and informed participants in it. > > d/ > > ps. Well, to be more complete, I assumed that IETF ownership meant > that the document was required to be publicly available and -- though > I didn't know the term at the time -- there was public permission for > derivative works by whoever felt like doing the deriving. These are good ideas to put in a "requirements for IETF copying license" document, as input to lawyers to craft legal text for. When translated into legal text, I believe the IETF cultural preference maps closely to the BSD license. None of the RFC policies around copyright (including RFC 2026, RFC 3978, and RFC 5378) are close to your assumptions. Most critically, none of the policies transfers copyrights from the contributor to the IETF. It is unfortunate that there has been such a big gap between the IETF policy texts and what many people with long IETF experience believe it should say. This complicated the IPR WG effort: rather than letting the new text map more closely to the IETF culture, the document authors re-used text from earlier documents. /Simon ___ 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
--On Wednesday, 17 December, 2008 20:29 -0800 Lawrence Rosen wrote: > Reply below. /Larry >... > [LR:] I am asking as an attorney and IETF participant (we're > all individuals here, I've been told, with individual > opinions) who is anxious to understand why so many people on > here are worried about copyright infringement and are seeking > to protect copyrights they don't even have the honesty to claim > outright. I care about IETF specifications in this email > thread, not about any specific clients. As to whether I might > represent one or more clients on this issue, my lips are > sealed. To answer a slightly different question, but one that may be more useful, the IETF was propelled along the path of specific policies, with the original ones clearly recognizing the "installed base", because of credible threats to block work unless everything were rewritten from scratch to (at least) remove all of the author's sentences. The situation I remember best involved work built on the author's text, but the WG consensus differed from the author's concepts in some ways he considered fundamental. I don't recall the details, but I believe that the threats extended at least into cease and desist letters, not just the usual profile of posturing, noise, and idle threats. I think it would be fair to summarize the thinking of the powers-that-be at the time as just not wanting to be the target of that kind of interaction and process, much less any legal action that might follow, regardless of estimates about who would prevail in such an action. You are, of course, entitled to any opinions you may have about whether that was the right decision and whether it was properly implemented. However, because it appeared nearly certain that any specific and well-funded legal effort would result in significant delays to the IETF's work, a large fraction of the community who were close to the issues --probably large enough to constitute rough consensus-- because extremely risk-adverse, where the perceived risk involved the "opportunity" for lost time, service of various documents and responses, preparation of other documents, interaction with courts, etc., rather than more specific questions about who would ultimately prevail. My apologies for not supplying specific names, dates, and descriptions of the incident, but there have also been threats of libel actions if the positions of the actors were not represented accurately (see risk-adversity and definition above) and, independent of that, I have no wish to resurrect the ghosts of that incident in the magical time of year (or ever). But we have certainly had people in the community who have tried to use copyright in document text to impede the IETF process and to strike out against people and actions of which they disapproved. Finally, for better or worse, your belief that "Both are absolutely essential for implementation of open standards" does not represent the consensus in the IETF community, or at least has not represented it so far, unless you use the term "open standards" in a way that makes it tautologically true. Certainly the FOSS community has managed to implement standards from, e.g., ITU, JTC1, and several ISO member bodies whose text is as or more restricted than anything the IETF has proposed. Perhaps that has been done on the basis of advice from you or others that no one is likely to actually try to enforce the intrinsic or claimed rights, but the organizations that hold those rights have not been persuaded to change their policies or claims as a result. I see a problem here, not necessarily because of claims someone might assert but because of claims that 5378 requires authors to assert. The latter turns this into a series of decisions by individuals and, in some situations, their employers. If even a few of them are sufficient adverse to the risk of getting tied up in legal proceedings, we end up in exactly the situation that we started down the path of IETF IPR policies to avoid -- significant delays to, or disruption of, the orderly progress of the standards process. Unless you are willing to give us legal advice on which we can rely (and presumably, with it, assurances that doing so would not put you in a potential conflict of interest with anyone [else] who might have retained you), your trying to make estimates of the likelihood of someone asserting claims (and/or prevailing if they did) don't help me or the IETF very much. But the core of the issue I'm having with your note is that I believe we have gotten ourselves into a situation that requires a solution in the near term. I see reintroducing an argument that everything should just be free (presumably as in "free beer") -- an argument that IETF WGs have rejected several times-- and the rehashed discussion that would follow as a distraction and impediment to getting to such a solution, not a help on the critical path to making progress. YMMD, of course, but let's be explicit about wh
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
FWIW my overall take on this is in line with Dave's. I also think EKR and Larry made good points. Basically, I'll just go with whatever xml2rfc produces at any given moment. Lastly, I can't really find the energy to get exercised by any of this, and wonder if interminable discussions like this are part of the reason folks keep away from all the well meaning attempts to revise IETF processes. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
On Dec 17, 2008, at 10:46 PM, Martin Duerst wrote: I *assume* it's the same as for the TM Licence at http://trustee.ietf.org/docs/IETF_General_TM_License.pdf, which would be: IETF Trust 1775 Wiehle Ave Reston, VA 201905108 c/o IETF Administrative Director Facsimile: 703.326.9881 This is correct. Alternatively, one could pdf a signed copy and email to i...@ietf.org. I am investigating automating the process and will keep you apprised of the possibility and progress. Ray IAD However, it would REALLY be good if the Contributor licence also contained the necessary details on how and where to submit. I have already made that suggestion on the IETF list. Regards,Martin. At 12:32 08/12/18, Randy Presuhn wrote: Hi - I've seen http://trustee.ietf.org/docs/Contributor_Non-Exclusive_License_RFC5378.pdf Where are we supposed to have our WG members send the signed forms? I'd like to get our WG unstuck, since IETF action on fixing RFC 5378 seems unlikely. Randy #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp ___ 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
On Thu Dec 18 11:08:09 2008, John C Klensin wrote: To answer a slightly different question, but one that may be more useful, the IETF was propelled along the path of specific policies, with the original ones clearly recognizing the "installed base", because of credible threats to block work unless everything were rewritten from scratch to (at least) remove all of the author's sentences. The situation I remember best involved work built on the author's text, but the WG consensus differed from the author's concepts in some ways he considered fundamental. I don't recall the details, but I believe that the threats extended at least into cease and desist letters, not just the usual profile of posturing, noise, and idle threats. It could well be that I'm misunderstanding, but that kind of situation would surely fall into "derogatory treatment", ie, the stuff covered by Article 6bis of the Berne convention, or, for UK people, the Copyright, Designs and Patents Act 1988 sections 80-83. In Berne language: the author shall have the right to claim authorship of the work and to object to any distortion, mutilation or other modification of, or other derogatory action in relation to, the said work, which would be prejudicial to his honor or reputation. And this sounds like, basically, what happened, at least from the perspective of the contributor. Note that moral rights are often not transferrable in various jurisdictions, and certainly aren't automatically transferred anywhere as far as I know - section 11bis seems to prevent that. Since these are moral rights, and not copyrights, and they're not mentioned at all by RFC 5378, surely the situation is entirely unchanged by this? To put it another way, if the intent here was to avoid a repeat of this incident, then what's needed here is a waiver of moral rights, rather than a license of copyrights, which is beyond my ability to figure out. (I am, incidentally, not a lawyer, for those living in jurisdictions which like to have that in writing somewhere). As another point, by submitting a document as author, I take it I am making the claim that all rights required under RFC 5378 are granted by all contributors, their employers, or estates, as appropriate - does this open me to litigation should a contributor I didn't know about complains? What if someone else submits the document, am I still liable? Where is the record of who submitted the document if not? (Presumably, once the document passes through AUTH48, I must be liable, having given explicit assent to it). To put this another way, is contributing a revised document to the IETF now too risky an action to contemplate? Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
On Dec 18, 2008, at 7:17 AM, Dave Cridland wrote:
On Thu Dec 18 11:08:09 2008, John C Klensin wrote:
To answer a slightly different question, but one that may be
more useful, the IETF was propelled along the path of specific
policies, with the original ones clearly recognizing the
"installed base", because of credible threats to block work
unless everything were rewritten from scratch to (at least)
remove all of the author's sentences. The situation I remember
best involved work built on the author's text, but the WG
consensus differed from the author's concepts in some ways he
considered fundamental. I don't recall the details, but I
believe that the threats extended at least into cease and desist
letters, not just the usual profile of posturing, noise, and
idle threats.
It could well be that I'm misunderstanding, but that kind of
situation would surely fall into "derogatory treatment", ie, the
stuff covered by Article 6bis of the Berne convention, or, for UK
people, the Copyright, Designs and Patents Act 1988 sections 80-83.
In Berne language:
the author shall have the right to claim authorship of the work and
to
object to any distortion, mutilation or other modification of, or
other
derogatory action in relation to, the said work, which would be
prejudicial
to his honor or reputation.
And this sounds like, basically, what happened, at least from the
perspective of the contributor. Note that moral rights are often not
transferrable in various jurisdictions, and certainly aren't
automatically transferred anywhere as far as I know - section 11bis
seems to prevent that.
Since these are moral rights, and not copyrights, and they're not
mentioned at all by RFC 5378, surely the situation is entirely
unchanged by this?
To put it another way, if the intent here was to avoid a repeat of
this incident, then what's needed here is a waiver of moral rights,
rather than a license of copyrights, which is beyond my ability to
figure out. (I am, incidentally, not a lawyer, for those living in
jurisdictions which like to have that in writing somewhere).
I have been involved a little in the US planning for various
negotiations of the inclusion of webcaster rights in the
WIPO under the Berne convention (I generally oppose what has been
proposed). At the risk of violating
my mantra ("Engineers should not try and be lawyers"), I do not think
we should go there or need to go there.
Note that, while the USA is not a signatory to the Rome Convention
(even though our WIPO negotiators
sometimes seem to like to act like we are), the USA is a signatory to
the Berne Convention :
http://www.copyrightaid.co.uk/copyright_information/berne_convention_signatories
However, Article 6bis(3) allows national legislatures to determine the
treatment of moral rights;
the USA has not done so. In fact, moral rights were a major sticking
point in the US's signing the Berne convention at all.
Under the "Berne Convention Implementation Act of 1988", 17 USC 101,
Section 2 (2)
"The obligations of the United States under the Berne Convention may
be performed only pursuant to appropriate domestic law."
The IETF Trust is governed under the laws of the Commonwealth of
Virginia, a state in the USA, so it is governed by US Law, not the
Berne convention directly.
In the Berne Convention Implementation Act of 1988, 17 USC 101,
Section 3 (b)
"(b) Certain Rights Not Affected.--The provisions of the Berne
Convention, the adherence of the United States thereto, and
satisfaction of United States obligations thereunder, do no expand or
reduce any right of an author of a work, whether claimed under
Federal, State, or the common law--
(1) to claim authorship of the work; or
(2) to object to any distortion, mutilation, or other modification of,
or other derogatory action in relation to, the work, that would
prejudice the author's honor or reputation."
If you want more, I would start here : http://www.rbs2.com/moral.htm
I would urge the IETF Trust to stick to US / Virginia law only.
Regards
Marshall
As another point, by submitting a document as author, I take it I am
making the claim that all rights required under RFC 5378 are granted
by all contributors, their employers, or estates, as appropriate -
does this open me to litigation should a contributor I didn't know
about complains? What if someone else submits the document, am I
still liable? Where is the record of who submitted the document if
not? (Presumably, once the document passes through AUTH48, I must be
liable, having given explicit assent to it).
To put this another way, is contributing a revised document to the
IETF now too risky an action to contemplate?
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemona
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Speaking as an individual, IANAL, etc., a few general comments... First, overall, the issues John raises are real and need to be addressed, IMO. Second, I know of cases (while I was AD) where a WG participant owned the copyright on an ID the WG had been discussing, and then balked at making requested changes. In at least one case, a document was rewritten in "clean room" fashion to get around potential problems. We do not want to do these sorts of things. They are painful and frustrating, they delay work, and they are a drain on precious cycles that could better be spent doing other things. Such scenarios may not happen often, but they can (and have) happened. Some former IETF participants have walked away from the IETF in a disgruntled fashion. In no way would it be acceptable for the IETF as an organization to allow anyone to have the potential ability to block IETF work by withholding any needed additional/new rights. Yet, that is what RFC 5378 appears to do. One of the "features" of the current IETF IPR (not copyright) policies is that each individual WG decides on a case-by-case basis what to do with IPR assertions. Those discussions are often messy, non-terminating and contentious because there are unknowns (i.e., unquantifiable future risk), and the normal rules engineers follow don't apply (e.g., the lawyers and licensing folk see issues very differently than engineers do). Different people (and companies) see the risks very differently. So what works for one individual won't work for someone else. Placing the responsibility on individual authors (and by implication their employers) for getting necessary permissions to use text contributions from others (e.g., when revising previous RFCs) is problematic when such permissions can't easily be obtained because: - it places unknown/hard to quantify future risk on the individual (who may or may or may not care) - by implication, it places future risk on their employer (who probably very much will care) One might hypothesize that some will say "this is silly" and just continue to submit documents without worrying much. Others (like those working for larger corporations) may well find that a general corporate policy will not allow them to take such steps (legal departments rarely issue blank checks for future unknown risk). Consequently, all cases will likely be treated as exceptions to be evaluated on individual merits and on a case-by-case basis. Anyone who has had significant interactions with legal departments on such matters will understand how problematic this would be in practice. There would be a huge discincentive to authoring work of this nature, and at best there would be (potentially lengthy) delays. Most likely, the pool of available authors would simply shrink. That would not be good for the IETF. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
http://trustee.ietf.org/docs/IETF_General_TM_License.pdf, which would be: IETF Trust 1775 Wiehle Ave Reston, VA 201905108 c/o IETF Administrative Director Facsimile: 703.326.9881 ok, i put an IETF logo on our sourceforge oage last week , please don´t sue me i will send a signed document in the next days. thanks for your appreciation marc However, it would REALLY be good if the Contributor licence I've seen -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 Köln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: m...@let.de jabber :m...@kgraff.net IRC: #opencu freenode.net twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. ___ 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
Silly question. Is this discussion more appropriate to ietf-ipr? One could argue that ietf-ipr looked at this question for two years prior to submitting the new boilerplate, and by missing it made it clear that they weren't adequate to review. That said, there was also an IETF last call, and none of us detected the issue until Sam brought it up. But really - isn't this about IPR? On Dec 17, 2008, at 1:05 PM, Dave CROCKER wrote: John C Klensin wrote: But both your comments and that "can't get it right" issue just reinforce my view that we either need an escape mechanism for old text or need a model in which the Trust, not the submitters, take responsibility for text Contributed to the IETF under older rules. For the record, I don't know how to make the latter work (partially because, like you, I try to avoid simulating a lawyer) and am not proposing it. I have held off proposing this latter view, because I've assumed it was obvious and that those expert in the legal issues rejected it. But from a practical standpoint, it is the most accurate representation of work done on IETF documents (within the working gorup structure.) That is: Working groups are part of the IETF and 'authors' of working group documents are acting as when writing IETF documents.agents of the IETF. While there might be underlying intellectual property owned by the companies that authors work for, the actual document is commissioned by, and copyright should be owned by, the IETF. Let me carry it further: When Erik Huizer and I wrote the first IETF Working Group Guidelines document, it was at our initiative. (Well, really, Erik's.) When it was adopted by the IETF, I automatically assumed that the IETF owned it. That is, after all, what we assert when outside technology is brought into the IETF and we insist that they are handing over "change control". What is change control if not the authority to make changes to the document? So when Scott Bradner did the revision to the IETF Working Group Guidelines document the idea that he had a legal obligation to get our permission would have -- and certainly now does -- strike me as silly. That's me talking as a participant, about pragmatics, not me pretending to be a attorney, talking about copyright law. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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: Gen-ART Last Call review of draft-ietf-ospf-lls-05.txt
Abhay, Spencer: Abhay Roy wrote: Thanks for the review. Please see inline for comments.. On 11/5/2008 8:34 AM, Spencer Dawkins wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ospf-lls-05.txt Reviewer: Spencer Dawkins Review Date: 2008-11-05 IETF LC End Date: 2008-11-10 Summary: This document is on the right track for publication as Proposed Standard. I have a couple of 2119 questions. Comments: The 16-bit LLS Data Length field contains the length (in 32-bit words) of the LLS block including the header and payload. Implementations MUST NOT use the Length field in the IP packet header to determine the length of the LLS data block. Spencer: I'm not sure this is a 2119 MUST NOT - aren't you just saying that if you try it, you'll fail? We discussed about it, and decided to remove the 2nd sentence above. The CA-TLV MUST only appear once in the the LLS block. Also, when present, this TLV SHOULD be the last TLV in the LLS block. Spencer: Why SHOULD and not MUST? At a minimum, I would expect to see some description of what should happen if CA-TLV is NOT the last TLV in the LLS block - and if the expectation is that processing continues, I'm not sure what this sentence means... The thinking was we could have found the TLV at a "fixed" location to speed up authenticating the LLS block. But after discussing more on it, we decided to get rid of this requirement. I think we should change it to MUST per Spencer's suggestion. I.e., make the CA-TLV the last in the LLS block. This makes it much easier to authenticate the LLS block without including the CA-TLV. Thanks, Liem I will make the changes in the next revision.. Regards, -Abhay ___ 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
--On Wednesday, 17 December, 2008 14:00 -0800 Randy Presuhn wrote: > Particularly since the permission to create derivative works > and successor standards has been granted as part of the > boilerplate for a long long time. Yes. But that was permission given directly by the authors to the IETF, for IETF use. 5378 removes that mechanism, which I always considered fairly elegant, in favor of a transfer of rights to the Trust which then licenses those rights back to the IETF participant. All 5.3 does is to give those rights to the Trust (read the first paragraph), and the Trust doesn't get them unless the author can and does make the assertions of 5.1 (which includes rounding up the prior contributors). >... > Consequently, as a WG co-chair who wants his WG to > finish up in this century, I read RFC 5378 section 5.3 as > giving working groups what they need so they can ignore all > this stuff about tracking down long-gone contributors, and > that it's merely a re-incarnation of what has long been the > intent behind the NOTE WELL text. What gives your WG the ability to function is 5.4, where the Trust gives back to the IETF participants what the Trust received under 5.1 and 5.3. But they can't give back what they don't have, so, if your WG is required to derive its permission to do work from 5.4 and a previous author takes a walk rather than making the 5.1 guarantees and 5.3 transfers _to the Trust_... My guess, with the usual non-lawyer disclaimers, is that we would be having a less complicated discussion if 5378 _preserved_ the direct grant from Contributors to the IETF for IETF use in addition to whatever it required be given to the Trust. That would let your WG (and Dave's revisions) continue to function under the old rules and assumptions even if we still needed to have a debate about whether 5378 conformance was required of every document posted, obligations on submitters, etc. >... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 5378: A Worked Example
> On Wed, 17 Dec 2008 07:40:30 -0800, Eric Rescorla > said: ER> That list contains 14 names. Let's say that I have a 95% chance of ER> getting any one of those people to give consent. The joint probability ER> that I will obtain all the required consents is .95^14, less than 1/2. ER> I imagine the situation is similar for other large, old ER> documents such as RFC 3261 (SIP) or 2616 (HTTP). The problem with both open processes and open source is that when they hit issues like this the tendency is to be either: 1) too loose 2) too strict We're now switching from #1 to #2. And switch is what's going to bite us. I'm sure that some of the contributors to some past documents aren't even alive which will make some of this paperwork really interesting. The only thing you can adjust in the above math is the success rate of your contacts. That means you need to improve your accuracy a bit Eric or you'll certainly fail! Maybe the IETF needs to hire a private investigator? The problem is that when it comes signing paperwork like that, I'd assume (not being a lawyer I'm good at assuming) that it's the company paying the individual that has to authorize at the least or more likely sign the paperwork. If the company and the individual are not on good terms or if the company doesn't exist any longer or has no recollection of even sending someone to the IETF because their "strategic directions" have changed that 95% may seem a bit too generous. Maybe it would be easier to start from scratch on everything and do a complete rewrite (by fresh people that have never read the previous documents and thus can't be influenced by the text). As far as actually operating in a "too strict" mode: some open-source projects require signing copyright assignment papers before they can contribute to the project (FSF does this, for example, before contributing to Emacs (or nearly everything else)). The downside, of course, is reduced contribution. The upside is you've successfully pulled of the "strictness" quite effectively. The downside of the IETF, however, is that contributions occur at the microphone and on public mailing lists. You could, I suppose, require everyone attending the IETF to sign a legal document assigning their contributions away. However, how many people have you all met that have come to the IETF (promising not to eat the cookies) without paying because they had no sponsor and couldn't afford it and gotten up to speak at the microphone? How many people contribute only on the mailing list without ever attending an IETF? How many chairs show the note-well screen at the start of each meeting long enough so that people actually could read it? How many chairs have forgotten to show it? How many people have read RFC5378 vs those that have not? I'm sure the overlap is a very non-zero. Until we get rfid chips that turn on the microphone and X.509 certs that state we're authorized to contribute to mailing lists I fail to see how all this helps. I suspect others are in the same boat of confusion. As I mentioned, I'm not a lawyer. But I don't see how publishing one document in a list of documents that currently numbers more than 5400 and expecting that everyone will abide by it will solve the issue. But what do I know? I'm not a layer so I don't understand the rules. I'm just somehow supposed to abide by the rules I don't understand. -- Wes Hardaker Sparta, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 5378: A Worked Example
Wes Hardaker wrote: > I'm not a layer so I don't understand the rules. > I'm just somehow supposed to abide by the rules I don't understand. Maybe we don't have a layering problem, we have a lawyering problem. Repeat after me: I am not a layer! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
On 17-Dec-08, at 11:06 AM, Scott Brim wrote: Mark Seery allegedly wrote on 11/30/08 10:38 AM: Some questions have also risen WRT identity: http://www.potaroo.net/presentations/2006-11-30-whoareyou.pdf Is identity a network level thing or an application level thing? Whatever. All of the above. There are many possible ways to use identifiers, particularly for "session" (whatever that is, at whatever layer) authentication and re-authentication. The point to locator/identifier separation is primarily to get identification- related functions to stop depending on location-dependent tokens, i.e. locators. Once that's done, they can use anything they like -- and they do :-). Agreed. They do. That does not mean that identity should not be an important part of the internet architecture. Note also that the paper above mixes identity with identifiers. They are not the same thing -- Dick ___ 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
Cullen Jennings wrote: > Larry, your email sounded dangerously close to suggesting that it > might be ok to break the copyright law because no one would object to > it. Is that what you are suggesting? Not at all. But every attorney is charged with an obligation to help others understand and interpret the law even if that interpretation differs from that of some other attorneys. Fifty years from now, after IETF is dissolved and most of us have passed away, I don't want the dead hand of copyright reaching out from the grave to prevent anyone from freely modifying TCP/IP to satisfy modern requirements. It may be that, because Congress further extends the copyright term, the Disney corporation will then still own and control the copyright in Mickey Mouse cartoons, but the notion that anyone owns and controls the functional underpinnings of technology by placing a copyright notice on it is simply unacceptable. That is a perversion of the law, not something that a copyright lawyer who supports open source, open content and open standards can countenance. I hope that the participants in IETF develop IPR policies that support the fundamental freedom to invent--and to describe in words--whatever functions we need for our world to progress. Best regards, /Larry > -Original Message- > From: Cullen Jennings [mailto:flu...@cisco.com] > Sent: Wednesday, December 17, 2008 10:24 PM > To: lro...@rosenlaw.com > Cc: 'IETF discussion list' > Subject: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary > > > Larry, your email sounded dangerously close to suggesting that it > might be ok to break the copyright law because no one would object to > it. Is that what you are suggesting? > > > On Dec 17, 2008, at 5:56 PM, Lawrence Rosen wrote: > > > Dave Crocker wrote: > >> That was the culture. Law often > >> follows culture, since culture creates established practice. > > > > I hope you're right. > > > > May I ask: Is there anyone on this list who is asserting a current > > copyright > > interest in any IETF RFC--on your own behalf or on behalf of your > > company--that would encumber the freedom of any IETF participants to > > copy, > > create derivative works, and distribute that RFC in accordance with > > IETF > > culture? > > > > On what basis do you assert that current copyright interest in those > > RFCs? > > Have you registered that copyright? Is that copyright interest sole > > or joint > > with any other entity, including other contributors or the IETF Trust > > itself? > > > > I'm not interested to hear about hypothetical situations. I would > > like to > > know if there are any actual claims of copyright ownership that > > people here > > are even considering to assert against IETF's complete freedom to > > act and > > establish functional Internet standards. > > > > /Larry > > > > > > > >> -Original Message- > >> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > >> Behalf Of > >> Dave CROCKER > >> Sent: Wednesday, December 17, 2008 3:34 PM > >> To: Brian E Carpenter > >> Cc: IETF discussion list > >> Subject: Re: IPR Questions Raised by Sam Hartman at the IETF 73 > >> Plenary > >> > >> > >> > >> Brian E Carpenter wrote: > >>> On 2008-12-18 11:32, Dave CROCKER wrote: > My assumption was that the IETF owned the work. Pure and simple. > >>> > >>> False. You never implicitly transferred ownership. > >> > >> > >> Yes I did. As I say, that was the culture. > >> > >> Scott didn't have to come to Erik or me and ask permission, and he > >> didn't > >> even > >> have to think about whether he was required to. That was the > >> culture. Law > >> often > >> follows culture, since culture creates established practice. > >> > >> I do realize that that was a long time ago and that we certainly > >> have many > >> participants holding different views. > >> > >> I was reviewing the history on the general belief that a crisis of > >> the > >> current > >> sort can often be aided by taking a fresh look at first principles. > >> > >> > >> > >> But since I've now had a number of public and private exchanges > >> with folk > >> who > >> have been diligent participants in this topic and since none has > >> seemed to > >> understand -- nevermind embrace -- the line of discussion I've > >> tried to > >> raise, > >> I'll go back to my observer status and let the folks who are > >> putting the > >> real > >> effort into this continue on. > >> > >> d/ > >> > >> > >> -- > >> > >> Dave Crocker > >> Brandenburg InternetWorking > >> bbiw.net > >> ___ > >> 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: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
--On Thursday, 18 December, 2008 09:10 -0800 Lawrence Rosen wrote: > Cullen Jennings wrote: >> Larry, your email sounded dangerously close to suggesting >> that it might be ok to break the copyright law because no one >> would object to it. Is that what you are suggesting? > > Not at all. But every attorney is charged with an obligation > to help others understand and interpret the law even if that > interpretation differs from that of some other attorneys. > > Fifty years from now, after IETF is dissolved and most of us > have passed away, I don't want the dead hand of copyright > reaching out from the grave to prevent anyone from freely > modifying TCP/IP to satisfy modern requirements. >... > ...the notion that anyone owns and controls the functional > underpinnings of technology by placing a copyright notice on > it is simply unacceptable. >... > I hope that the participants > in IETF develop IPR policies that support the fundamental > freedom to invent--and to describe in words--whatever functions > we need for our world to progress. Larry, Now I'm confused. To my weak, layperson's, mind, it appears that you are conflating the underlying intellectual property in TCP/IP (whatever, if anything, that means), or the "functional underpinnings of [that] technology", with the copyright in the form in which the protocols are expressed -- something that you and your professional colleagues have repeatedly warned us against. I would assume that, if someone were revising TCP or IP fifty years hence, they would end up creating new text, rather than moving a lot of technical text forward, and that they would do so for all sorts of technical reasons independent of copyright constraints.The practical issues are very different from tweaking an existing protocol only a decade or so out (or somewhat more) to clarify it or change its maturity level... and, of course, are different from the image of a cartoon mouse. As an exercise that I don't have time to conduct, it would be interesting to see how much of the text of the original IP specification is still present in the IPv6 one... and that was only 20 years and may, in retrospect, have involved too few substantive changes. > That is a perversion of the law, not something that a > copyright lawyer who supports open source, open content and > open standards can countenance. Which is something about which you need to persuade the Congress, not the IETF, as I assume you have tried to do. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Why do we need to send these license forms in at all? I thought the requirement was that the authors get the necessary rights. Are you just conveniently keeping track for us? ___ 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
John C Klensin writes: > As an exercise that I don't have time to conduct, it would be > interesting to see how much of the text of the original IP > specification is still present in the IPv6 one... and that was > only 20 years and may, in retrospect, have involved too few > substantive changes. I wouldn't spend a lot of time on such an exercise. I'd be very surprised if there is ANY common text. All the documents I am aware of were written from scratch. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
On Thu, Dec 18, 2008 at 02:14:44PM -0500, Sam Hartman wrote: > Why do we need to send these license forms in at all? > > I thought the requirement was that the authors get the necessary > rights. Are you just conveniently keeping track for us? I think it will make it easier to get proof of the necessary rights having been granted if there's a repository that makes available the names of those who have granted the rights once and for all. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
On Dec 18, 2008, at 2:21 PM, Andrew Sullivan wrote: On Thu, Dec 18, 2008 at 02:14:44PM -0500, Sam Hartman wrote: Why do we need to send these license forms in at all? I thought the requirement was that the authors get the necessary rights. Are you just conveniently keeping track for us? I think it will make it easier to get proof of the necessary rights having been granted if there's a repository that makes available the names of those who have granted the rights once and for all. Concur. Names will be posted. Ray A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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
John C Klensin wrote: > I would assume that, if someone were revising TCP or IP fifty > years hence, they would end up creating new text, rather than > moving a lot of technical text forward, and that they would do > so for all sorts of technical reasons independent of copyright > constraints. Now I'm confused. When we revise a technical specification in IETF, we try (to some degree) to avoid creating new text unless necessary, for fear of introducing subtle incompatibilities. Why wouldn't "someone" fifty years hence have similar concerns? I'll grant that the text in a lot of these old RFCs looks a bit dated and imprecise by now. But if I were revising TCP, I'd still use RFC 793 as a starting point, and the resulting documents would probably qualify as "derivative works". Keith p.s. Regarding the IPv4 to IPv6 comparison, one could argue that the IPv6 spec _should_ have included more text from RFC 793, as there are indeed subtle differences between the IPv4 and IPv4 protocols that have caused unanticipated problems. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
On Dec 18, 2008, at 2:14 PM, Sam Hartman wrote: Why do we need to send these license forms in at all? I thought the requirement was that the authors get the necessary rights. Are you just conveniently keeping track for us? I would envision folks providing 5378 licenses to the Trust or their pre-5378 work. If licenses are submitted their names could be posted online for other Contributors to ascertain whether a pre-existing work has been so licensed. Ray ___ 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
--On Thursday, 18 December, 2008 14:15 -0500 Thomas Narten wrote: > John C Klensin writes: > >> As an exercise that I don't have time to conduct, it would be >> interesting to see how much of the text of the original IP >> specification is still present in the IPv6 one... and that was >> only 20 years and may, in retrospect, have involved too few >> substantive changes. > > I wouldn't spend a lot of time on such an exercise. I'd be very > surprised if there is ANY common text. All the documents I am > aware of were written from scratch. That is pretty much what I expected. To the extent to which we can extrapolate from it (and I think we can), Larry's concern about copyright-blockage on such work is probably not significant. john ___ 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
--On Thursday, 18 December, 2008 14:42 -0500 Keith Moore wrote: > John C Klensin wrote: > >> I would assume that, if someone were revising TCP or IP fifty >> years hence, they would end up creating new text, rather than >> moving a lot of technical text forward, and that they would do >> so for all sorts of technical reasons independent of copyright >> constraints. > > Now I'm confused. When we revise a technical specification in > IETF, we try (to some degree) to avoid creating new text > unless necessary, for fear of introducing subtle > incompatibilities. Why wouldn't "someone" fifty years hence > have similar concerns? Because there is a big difference between clarifying or updating an existing spec and writing a new protocol. > I'll grant that the text in a lot of these old RFCs looks a > bit dated and imprecise by now. But if I were revising TCP, > I'd still use RFC 793 as a starting point, and the resulting > documents would probably qualify as "derivative works". That would be your choice. And you are a lot more likely to be around 50 years from now to make it than I am. However, trying to write a new spec with IPR that conforms to 5378 but that used significant text from 783 would require you to obtain Jon Postel's permission which, I think, would send you swimming in a can of worms of appropriate size for you to do so. So, to write such a spec with 783 text, you would either have to un-do 5378, create the type of exception procedure that caused the current version of this thread to be initiated, or deal with that can or worms. It would be up to you to determine which of those options would be most attractive... or whether a complete rewrite or giving up entirely would. Q.E.D. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sieve-mime-loop (Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure) to Proposed Standard
At 16:44 05-12-2008, The IESG wrote: The IESG has received a request from the Sieve Mail Filtering Language WG (sieve) to consider the following document: - 'Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the This nit is not relevant to the Last Call. draft-ietf-sieve-mime-loop-08 is dated November 20, 2008. It expires on May 24, 2009. The status of the memo mentions that drafts are valid for a maximum of six months. Section 5 of the document defines an action where the subject or author of a message can be modified. A new header field, Original-Subject, is defined to preserve the previous subject header. A header field defined in a Standard Track RFC can be co-opted by other RFCs. Such use is generally encouraged as long as the definition of the header is not changed. It's common, even on IETF mailing lists, to see the subject line being rewritten. Given the way the Original-Subject is defined in this document, it's difficult to reuse that header. An Original-From header field is also defined in that section. The document does not provide a rationale for preserving the From header given that the changes are being done by the recipient of the message. "Implementations MAY also impose restrictions on what addresses can be specified in a ":from" parameter;" RFC 5322 specifies that: "In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. See also section 3.6.3 for more information on forming the destination addresses for a reply." The wording in this document may be read as loosening that restriction. If the entire message is being replaced, it is a new message. As such, the From header should specify the author, i.e. the mailbox(es) of the person(s) or system(s) responsible for the writing of the message (RFC 5322 Section 3.6.2). There is no mention of what should be done if the message contains a Message-ID field. As the Message-ID is unique message identifier that refers to a particular version of a particular message, a new one would have to be generated if we consider the message as a new one. If we are changing the author, then the message should be viewed as a new instantiation of the message. Is there a need for Original-Subject and Original-From headers as defined in this specification? Please change the reference from RFC2822 to RFC5322. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Ray Pelletier writes: > On Dec 18, 2008, at 2:14 PM, Sam Hartman wrote: > >> Why do we need to send these license forms in at all? >> >> I thought the requirement was that the authors get the necessary >> rights. Are you just conveniently keeping track for us? > > I would envision folks providing 5378 licenses to the Trust or their > pre-5378 work. If licenses are submitted their names could be posted > online for other Contributors to ascertain whether a pre-existing > work has been so licensed. How does this help contributors use the older material? As far as I understood the rules, it is the author that needs to get the necessary rights from the original contributor before submitting it to the IETF. The form appears to give the necessary rights from the original contributor to the IETF Trust, not to the authors. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
On Dec 18, 2008, at 4:12 PM, Simon Josefsson wrote: Ray Pelletier writes: On Dec 18, 2008, at 2:14 PM, Sam Hartman wrote: Why do we need to send these license forms in at all? I thought the requirement was that the authors get the necessary rights. Are you just conveniently keeping track for us? I would envision folks providing 5378 licenses to the Trust or their pre-5378 work. If licenses are submitted their names could be posted online for other Contributors to ascertain whether a pre-existing work has been so licensed. How does this help contributors use the older material? As far as I understood the rules, it is the author that needs to get the necessary rights from the original contributor before submitting it to the IETF. The form appears to give the necessary rights from the original contributor to the IETF Trust, not to the authors. Good point. Probably need to update Trust Policy - I'll check into it. Ray /Simon ___ 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
tell you what - if by some very small chance (probably less than 1%) I'm still around 50 years from now and feel like revising RFC 793 at that time, I'll trust that you've already reconnected with Jon and gotten his permission :) either that, or I'll already be dead, and I'll ask him myself. seriously, my guess is that 50 years from now, either TCP will be irrelevant (if not the whole Internet) or RFC 5378 will have been fixed. and those two are not independent. Keith ___ 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
> "Keith" ==writes: Keith> tell you what - if by some very small chance (probably less Keith> than 1%) I'm still around 50 years from now and feel like Keith> revising RFC 793 at that time, I'll trust that you've Keith> already reconnected with Jon and gotten his permission :) Keith> either that, or I'll already be dead, and I'll ask him Keith> myself. I tell you what. I'll trust that Jon or his estate is not going to sue us if we use his work in the IETF context to make new internet standards. Remember, we're discussing legalities here and for the most part US civil law. There are some things you decide are acceptable risks simply because the chance someone with standing to do so will take action against you are small enough that you stop caring. It's not an perfect world from an engineering standpoint, but guess what? There is not perfect compliance with our specs either. So, honestly, Jon's text is just not something I'm worried about even today. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Hi - (I trimmed the CC list, assuming that the WG chairs and Trustees that care about this stuff are already listening to the IETF discussion.) > From: "Ray Pelletier" > To: "Sam Hartman" > Cc: "Martin Duerst" ; "Randy Presuhn" > ; "Working Group Chairs" ; "IETF Discussion" ; "Trustees" > Sent: Thursday, December 18, 2008 12:26 PM > Subject: Re: where to send RFC 5378 license forms > > > On Dec 18, 2008, at 2:14 PM, Sam Hartman wrote: > > > Why do we need to send these license forms in at all? > > > > I thought the requirement was that the authors get the necessary > > rights. Are you just conveniently keeping track for us? > > I would envision folks providing 5378 licenses to the Trust or their > pre-5378 work. If licenses are submitted their names could be posted > online for other Contributors to ascertain whether a pre-existing > work has been so licensed. ... >From this list of names and the content of a pre-5378 RFC, how can a contributor ascertain that that pre-existing work has been licensed in its entirety? Suppose, for example, it contained an extended passage which was submitted to the working group either on a mailing list or hammered out in a face-to-face session, but is not identified as such. Particularly in the latter case (but also in the case of incomplete WG archives) there doesn't appear to be any reasonable way for a contributor to make this determination with much confidence. 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? 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? Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: where to send RFC 5378 license forms
> 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. > 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
Re: where to send RFC 5378 license forms
Jorge, I'm working on the assumption that once a contributor or a contributor's assign has signed the license form in its RFC5378 version, we can all submit drafts including that contributor's earlier text without further ado. Is that correct? Brian On 2008-12-19 11:37, 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. > >> 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 > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: where to send RFC 5378 license forms
> -Original Message- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Thursday, December 18, 2008 5:52 PM > To: Contreras, Jorge > Cc: Randy Presuhn; IETF Discussion > Subject: Re: where to send RFC 5378 license forms > > Jorge, > > I'm working on the assumption that once a contributor or a > contributor's assign has signed the license form in its > RFC5378 version, we can all submit drafts including that > contributor's earlier text without further ado. Is that correct? > > Brian That's right. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Hi - > From: "Contreras, Jorge" > To: "Randy Presuhn" ; "IETF Discussion" > > Sent: Thursday, December 18, 2008 2:37 PM > Subject: RE: where to send RFC 5378 license forms ... > The boilerplate text is owned by the IETF Trust. No author permissions > are needed. This is good news. Who owns the oft-repeated The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. > > 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. I'm referring to the bits effectively required by the MIB doctors, e.g.: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of ... and For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. and various incarnations of this stuff that appear in the text of RFCs that happen to contain MIB modules, not the stuff that's in the MIB modules. (Earlier versions of this were rather lengthy.) Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: where to send RFC 5378 license forms
> Who owns the oft-repeated >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this >document are to be interpreted as described in [RFC2119]. > I'm referring to the bits effectively required by the MIB > doctors, e.g.: >This memo defines a portion of the Management Information > Base (MIB) >for use with network management protocols in the Internet > community. >In particular, it defines a basic set of managed objects for Simple >Network Management Protocol (SNMP)-based management of ... > > and >For a detailed overview of the documents that describe the current >Internet-Standard Management Framework, please refer to > section 7 of >RFC 3410 [RFC3410]. > >Managed objects are accessed via a virtual information > store, termed >the Management Information Base or MIB. MIB objects are generally >accessed through the Simple Network Management Protocol (SNMP). >Objects in the MIB are defined using the mechanisms defined in the >Structure of Management Information (SMI). This memo > specifies a MIB >module that is compliant to the SMIv2, which is described > in STD 58, >RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 >[RFC2580]. > > and various incarnations of this stuff that appear in the text of RFCs > that happen to contain MIB modules, not the stuff that's in > the MIB modules. > (Earlier versions of this were rather lengthy.) I will check into this. Ideally, all boilerplate would be owned by the IETF Trust, but I am not aware that anyone has ever focused on this material. Technically, the copyright owner would be the author(s) who wrote the first document that says those words. However, the copyright in such generic phrases is vestigial at best. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-mmusic-file-transfer-mech-09
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an SDP syntax for signaling MSRP sessions that are to be used *only* for a specific file transfer. I highlight the word "only" because MSRP can already be used for file transfers, but the intent of an SDP peer to use a particular MSRP session to transfer a file cannot be signaled in SDP. This document adds syntax to SDP for that signaling. Given the fact that MSRP can already handle file transfers, I was expecting this document to address the security trade-offs associated with explicitly signaling these transfers. The current Security Considerations section focuses more on the traditional considerations around confidentiality and integrity of files transferred over this mechanism, without referencing the existing mechanisms in MSRP itself (RFC 4975). Overall, the document is well-written and comprehensible. However, there are a few ambiguities in the main text, and some significant repairs that need to be made to the Security Considerations. SECURITY COMMENTS: 1. The first paragraph of Section 10 is a non-sequitur: Lying about the attributes defined in this document has nothing to do with integrity-protection. The file sender can send a bad file that's still bit-for-bit perfect as it goes over the wire. What this section should recommend instead is that the file receiver MUST validate all available parts of the file-selector attribute (in addition to integrity protection). Similar text should be added to Section 8.2.2 and 8.3.2. This validation prevents the file sender from lying about what he's sending, and it prevents attackers that can't see the signaling from sending bad files to the file receiver. 2. The third paragraph of the Security Considerations (and parts of the first two) should be replaced by a reference to RFC 4975, which has a much more thorough discussion of integrity and confidentiality for MSRP. 3. There is no discussion of (1) authentication of file receivers or (2) authorization of file transfers. Given that this extension enables the "pull" pattern, this discussion is critical. For example, there's nothing in this document to recommend that my UA not blindly return any file that another UA asks for. I would recommend adding some text that file transfers MUST be authorized by the file sender's local policy, and that this authorization process MAY require that the file receiver be authenticated. The latter requirement will need some discussion of authentication, which can primarily be dealt with by referring to RFC 4975. OTHER COMMENTS: 1. The document discusses in detail when a change of file selector or file-transfer-id should trigger a new transmission. The document also seems to assume that a new transmission is only initiated after the first transmission is canceled. It's not clear (to me, anyway) whether this is in fact necessary, or whether a "new file transfer operation" (as in Figure 3) could be initiated without canceling the current operation. (Perhaps there's a port constraint here?) 2. In Section 8.2.1, why is "name" a MAY for inclusion in the file selector, while the others are MUSTs? 3. In Section 8.2.2, shouldn't it be "The file receiver ... MUST add at least one of the selectors defined..." (instead of SHOULD)? What would it mean for the recipient to send a blank file-selector? "Send me a file! Any file!"? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 148 messages in the last 7 days. script run at: Fri Dec 19 00:53:02 EST 2008 Messages | Bytes| Who +--++--+ 12.16% | 18 | 15.08% | 139575 | john-i...@jck.com 9.46% | 14 | 8.76% |81024 | si...@josefsson.org 6.08% |9 | 4.88% |45120 | mo...@network-heretics.com 5.41% |8 | 4.93% |45649 | d...@dcrocker.net 4.73% |7 | 4.61% |42700 | brian.e.carpen...@gmail.com 4.05% |6 | 4.53% |41916 | t...@multicasttech.com 2.70% |4 | 3.46% |32050 | lro...@rosenlaw.com 3.38% |5 | 2.71% |25087 | rpellet...@isoc.org 2.70% |4 | 2.88% |26638 | nar...@us.ibm.com 2.70% |4 | 2.83% |26194 | randy_pres...@mindspring.com 2.70% |4 | 2.10% |19438 | hartmans-i...@mit.edu 1.35% |2 | 3.40% |31452 | pba...@verisign.com 2.70% |4 | 1.95% |18008 | e...@networkresonance.com 2.03% |3 | 2.36% |21818 | flu...@cisco.com 2.03% |3 | 2.32% |21440 | j...@joelhalpern.com 2.03% |3 | 1.69% |15599 | s...@employees.org 2.03% |3 | 1.66% |15402 | jorge.contre...@wilmerhale.com 2.03% |3 | 1.56% |14473 | julian.resc...@gmx.de 2.03% |3 | 1.48% |13696 | hous...@vigilsec.com 1.35% |2 | 1.35% |12505 | s...@resistor.net 0.68% |1 | 2.01% |18632 | bapti...@publicroot.org 1.35% |2 | 1.23% |11410 | dcroc...@bbiw.net 1.35% |2 | 1.23% |11338 | due...@it.aoyama.ac.jp 1.35% |2 | 1.02% | 9416 | m...@let.de 1.35% |2 | 0.92% | 8503 | stpe...@stpeter.im 0.68% |1 | 1.08% |10005 | brynosau...@gmail.com 0.68% |1 | 0.91% | 8375 | f...@cisco.com 0.68% |1 | 0.81% | 7472 | dw...@cisco.com 0.68% |1 | 0.80% | 7433 | spen...@wonderhamster.org 0.68% |1 | 0.79% | 7341 | d...@cridland.net 0.68% |1 | 0.77% | 7103 | ciscowo...@gmail.com 0.68% |1 | 0.76% | 7038 | rbar...@bbn.com 0.68% |1 | 0.75% | 6979 | wjh...@hardakers.net 0.68% |1 | 0.73% | 6730 | lhngu...@cisco.com 0.68% |1 | 0.70% | 6473 | a...@cisco.com 0.68% |1 | 0.68% | 6247 | robert.thur...@sun.com 0.68% |1 | 0.67% | 6226 | huit...@windows.microsoft.com 0.68% |1 | 0.66% | 6126 | sc...@kitterman.com 0.68% |1 | 0.65% | 6056 | j...@jck.com 0.68% |1 | 0.65% | 6054 | har...@alvestrand.no 0.68% |1 | 0.65% | 6006 | stephen.farr...@cs.tcd.ie 0.68% |1 | 0.65% | 5973 | stig.ven...@uninett.no 0.68% |1 | 0.64% | 5950 | tglas...@earthlink.net 0.68% |1 | 0.62% | 5754 | raeb...@mit.edu 0.68% |1 | 0.60% | 5582 | dick.ha...@gmail.com 0.68% |1 | 0.60% | 5552 | melinda.sh...@gmail.com 0.68% |1 | 0.53% | 4918 | jo...@iecc.com 0.68% |1 | 0.48% | 4433 | les...@thinkingcat.com 0.68% |1 | 0.45% | 4145 | e...@rtfm.com 0.68% |1 | 0.45% | 4121 | fen...@fenron.com 0.68% |1 | 0.45% | 4120 | a...@shinkuro.com 0.68% |1 | 0.41% | 3810 | paul.hoff...@vpnc.org 0.68% |1 | 0.41% | 3773 | hartm...@mit.edu 0.68% |1 | 0.38% | 3518 | s...@harvard.edu 0.68% |1 | 0.31% | 2903 | ch...@ietf.org +--++--+ 100.00% | 148 |100.00% | 925299 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Simon Josefsson skrev: Ray Pelletier writes: On Dec 18, 2008, at 2:14 PM, Sam Hartman wrote: Why do we need to send these license forms in at all? I thought the requirement was that the authors get the necessary rights. Are you just conveniently keeping track for us? I would envision folks providing 5378 licenses to the Trust or their pre-5378 work. If licenses are submitted their names could be posted online for other Contributors to ascertain whether a pre-existing work has been so licensed. How does this help contributors use the older material? As far as I understood the rules, it is the author that needs to get the necessary rights from the original contributor before submitting it to the IETF. The form appears to give the necessary rights from the original contributor to the IETF Trust, not to the authors. If the Trust has those rights, it's licensing them to all participants under the same terms as post-5378 works. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
