Re: RFC5378 alternate procedure (was: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary)
Hi. I've just reposted this draft as draft-klensin-rfc5378var-01.txt. I didn't removing the material I indicated I was going to remove because this version follows too quickly on the previous one. There are only two sets of changes, but the first seemed sufficiently important to be worth a quick update: (1) Alfred Hoenes caught several places in which I had transposed digits or otherwise fouled up RFC numbers to which I was making reference. This type of work is sufficiently confusing without that sort of stupid problem, for which I apologize -- I thought I had proofread it carefully enough but obviously did not. They have been fixed. (2) I realized that it was necessary for completeness to un-obsolete 3948 and 4748 if they were going to be referenced, or material from them picked up and copied into, documents, so I have inserted a paragraph to take care of that. Anyone who has successful read the -00 version and understood it can safely ignore this one. Anyone who has not yet read -00, or who tried to read it and was confused by the numbering errors, may find this version more helpful. Comments are, of course, welcome on either one. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Time for a sign-up campaign [Re: IPR Questions Raised by Sam Hartmanat the IETF 73 Plenary]
At 04:56 08/12/13, Brian E Carpenter wrote: >I hereby extend the rights in my contributions that I have personally >granted in the past to the IETF and to the IETF Trust to include >the additional rights required by RFC5378. Obviously by doing so, >I cannot extend the rights granted by my various employers. > >I'm going to print the updated license from >http://trustee.ietf.org/authorlic.html >and sign it and send it in. (My name is there because I signed >the older version.) Thanks for the pointer. However, it would be helpful if that page contained *short and simple* instructions on how to proceed with signing, e.g. along the following lines: - Print out licence (two copies? (2)) - Sign (on the "By" line, puting your name in print on the "Name" line and the date you signed on the "Date" line) (1) (two copies?) - Send to: [exact address of IETF Trust] - You will get back a copy signed by Ray in a few weeks. (2) (1) Especially the meaning of the "By" line won't be clear to people not from the US/not speaking English as their mother tongue. (2) It's unclear whether two copies are needed, and whether we'll get something back,... Regards,Martin. >I'm disappointed at how few people have signed up. Even people who've >been active in this debate haven't signed up to the old version. >We should surely all be signing up to the new version, if we've ever >made any kind of contribution in the past. We should all be pressing >our employers to sign up. > >The problem that Sam raised will become a minor concern if the vast >majority of us sign up. > > Brian Carpenter >___ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf #-#-# 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: Time for a sign-up campaign [Re: IPR Questions Raised by Sam Hartmanat the IETF 73 Plenary]
At 04:56 08/12/13, Brian E Carpenter wrote: >I hereby extend the rights in my contributions that I have personally >granted in the past to the IETF and to the IETF Trust to include >the additional rights required by RFC5378. Obviously by doing so, >I cannot extend the rights granted by my various employers. > >I'm going to print the updated license from >http://trustee.ietf.org/authorlic.html >and sign it and send it in. (My name is there because I signed >the older version.) Oh, so you're saying that we have a list of names where we don't really know who signed what (the older or the newer version)? I hope that can be fixed! (well, the easiest way to fix it would be for all those already on the list to upgrade :-) Regards,Martin. >I'm disappointed at how few people have signed up. Even people who've >been active in this debate haven't signed up to the old version. >We should surely all be signing up to the new version, if we've ever >made any kind of contribution in the past. We should all be pressing >our employers to sign up. > >The problem that Sam raised will become a minor concern if the vast >majority of us sign up. > > Brian Carpenter >___ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf #-#-# 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: RFC5378 alternate procedure (was: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary)
John, I like the draft. It looks like a fairly pragmatic approach to solve the problem. I believe it would allow us to continue work where the text had been provided under the 3978 rules. Without something like this, I don't know how I can submit new versions of the WG internet drafts that I am an co-author of. I can not even figure out who are all the people that contributed significant text to the WG drafts much less imagine how I will get permission from all of them to submit the draft under the the 5378 rules. Cullen On Dec 15, 2008, at 1:27 PM, John C Klensin wrote: Hi. In an attempt to get this discussion unstuck and to provide a way forward for those of us whose reading of 5378 (or advice from counsel) have convinced us that we cannot post most documents that contain older text written by others under the new rules, I've posted a new I-D, draft-klensin-rfc5378var-00.txt. It would be very helpful if people would actually read the draft before commenting on it -- it isn't very long, and the key section that contains the new procedure (Section 4) is under 40 lines of text -- but the intent is to make sure we don't get stuck or that we get unstuck as quickly as possible. While the draft reviews the history and context of the situation, the elevator summary of the proposal is that, if an author/ contributor is working on a document that contains old text and concludes that he or she cannot reasonably comply with the provisions of 5378, then it is permitted to post the document with IPR rules that are strictly in conformance with RFC 3978. In deference to the ever-patient and underappreciated maintainers of tools, I note that this would require no changes other than disabling (or later un-enabling) the 5378-only check that I assume the Secretariat is going to turn on tomorrow. A different possibility would be to create an exception procedure in which such an author would have to request an exemption from the IESG or the Trustees (or for the IESG to conclude that the variance procedure of RFC 2026 could be used for these cases). My personal opinion is that those approaches would add to the workload of people who are already too busy and further bog us down. This draft is not intended as a long term solution. Long-term, I think we will need to revise 5378 to make explicit provision for new documents that contain older material for which having the IETF Trust obtain additional rights is not feasible. The draft discusses that situation further. But I don't believe that we should even attempt to make that sort of change quickly, especially since I am very sensitive to Simon's comment from earlier today that I would generalize as "every time a new issue comes up, we respond by making things more complex and harder to understand and work with". So, in the short term, I hope this document will either provide a basis for the new BCP that Russ indicated that the Trustees need or at least can focus enough discussion that someone else can generate such a BCP draft. 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: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
On Dec 15, 2008, at 5:14 AM, Simon Josefsson wrote: "AJ Jaghori" writes: Modifying an author's original work without specified permission; regardless of new findings, constitutes a copyright infringement. Sure, but the old RFC copyright license (e.g., RFC 2026 and RFC 3978) gave IETF participants the necessary rights to allow modifications of earlier IETF work within the IETF standard process. The new one doesn't, and the consequences of that situation is what's discussed. My understanding (IANAL and other warning apply) is that the new license does do this, inside the IETF. It's grants to other organizations which is the issue. Regards Marshall /Simon On 12/13/08, Christian Huitema wrote: You can improve any technology you want, modulo IPR -- that's not the point here. The problem is taking existing copyrighted text and using it as a base for describing your technology. That's indeed the problem we stumbled upon years ago. Suppose that a contributor has written a complete description of technology X, getting it published as a 100 pages RFC. A remarkable feat, and a great contribution to the community. A few years letter, the working group realizes that they like the technology, but would like to change a couple options. That normally translates into changing a paragraph or two, resulting in a new RFC, more than 90% identical to the previous one. Suppose now that for whatever reasons, the original author disagrees with the changes, or with the new management of the working group, or with the new editor. People are human, these things do happen. IANAL, but my understanding at the time was that the original copyright still applied to the original text, and that the working group would be left with only bad options. They could issue a delta RFC that only contained the modifications, but that is somewhat confusing for the readers. Or they could undertake a complete rewriting of the standard, but that takes a long time and is also prone to errors and confusion. This is very much why we got the statement on copyrights in RFC 1602, in 1996. You will notice that copyrights were only mentioned as something we might need to worry about later in the appendix of the previous rules, RFC 1310 published in 1992. -- Christian Huitema ___ 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
RFC5378 alternate procedure (was: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary)
Hi. In an attempt to get this discussion unstuck and to provide a way forward for those of us whose reading of 5378 (or advice from counsel) have convinced us that we cannot post most documents that contain older text written by others under the new rules, I've posted a new I-D, draft-klensin-rfc5378var-00.txt. It would be very helpful if people would actually read the draft before commenting on it -- it isn't very long, and the key section that contains the new procedure (Section 4) is under 40 lines of text -- but the intent is to make sure we don't get stuck or that we get unstuck as quickly as possible. While the draft reviews the history and context of the situation, the elevator summary of the proposal is that, if an author/ contributor is working on a document that contains old text and concludes that he or she cannot reasonably comply with the provisions of 5378, then it is permitted to post the document with IPR rules that are strictly in conformance with RFC 3978. In deference to the ever-patient and underappreciated maintainers of tools, I note that this would require no changes other than disabling (or later un-enabling) the 5378-only check that I assume the Secretariat is going to turn on tomorrow. A different possibility would be to create an exception procedure in which such an author would have to request an exemption from the IESG or the Trustees (or for the IESG to conclude that the variance procedure of RFC 2026 could be used for these cases). My personal opinion is that those approaches would add to the workload of people who are already too busy and further bog us down. This draft is not intended as a long term solution. Long-term, I think we will need to revise 5378 to make explicit provision for new documents that contain older material for which having the IETF Trust obtain additional rights is not feasible. The draft discusses that situation further. But I don't believe that we should even attempt to make that sort of change quickly, especially since I am very sensitive to Simon's comment from earlier today that I would generalize as "every time a new issue comes up, we respond by making things more complex and harder to understand and work with". So, in the short term, I hope this document will either provide a basis for the new BCP that Russ indicated that the Trustees need or at least can focus enough discussion that someone else can generate such a BCP draft. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The Great Naming Debate (was Re: The internet architecture)
I absolutly agree with brians posting and recomment all people reading this paper , IMHO, it solves some known problems , even when they don´t exist in real world yet . ;) http://pdos.csail.mit.edu/papers/uia:osdi06.pdf (e.g., via DNS-based load balancers that take end-to-end IP reachability information as input), this would take us beyound round robin indeed. cheers Marc -- 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 PGP/GnuPG: 0x1ac02f3296b12b4d 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: The Great Naming Debate (was Re: The internet architecture)
This is a very anal retentive discussion your all having here. I support Ford here. Applications should be able to use names and IP addresses. We don't need the IP or DNS gestapo taking over application programs. regards joe baptista On Sun, Dec 14, 2008 at 2:51 PM, Bryan Ford wrote: > So, after being distracted by OSDI last week, I'm now trying to catch up on > the raging debates on TAE that are already exceeding all the wildest dreams > I had before setting up the list... :) > > On the issue of weaning applications (and potentially transports) away from > IP addresses in favor of names of some kind, I feel that a lot of the > disagreement results from a misunderstanding of exactly what I (and perhaps > others who have made similar proposals) was proposing... > > On Dec 4, 2008, at 10:29 PM, Keith Moore wrote: > >> Hallam-Baker, Phillip wrote: >> >>> I am trying to parse this claim. >>> >>> Are you saying that the DNS is fragile and raw IP relatively robust? >>> >> >> DNS is layered on top of IP. So for a large class of IP failures, DNS >> won't work either. And if IP routing fails, DNS is likely to be >> irrelevant because the application using DNS won't work anyway. >> >> And in practice, DNS is quite likely to fail due to configuration >> errors, inadequate provisioning, outdated cache entries due to >> unanticipated changes, brain-damaged DNS caches built into NATs, failure >> of registries to transfer a DNS name in a timely fashion, etc. >> >> So it's not a question of whether DNS is less reliable than IP (it is), >> or even whether the reliability of DNS + IP is less than that of IP >> alone (it is). It's a question of whether increasing reliance on DNS by >> trying to get apps and other things to use DNS names exclusively, makes >> those apps and other things less reliable. And I'd argue that it does, >> except perhaps in a world where renumbering happened frequently, at >> irregular intervals, and without notice. And I don't think that's a >> realistic scenario. >> > > I entirely agree in principle with your concerns about reliability: if > everything has to work correctly in two layers (DNS and IP), then that's > strictly less likely to happen than hoping everything will work correctly in > only one layer (just IP) - unless DNS can somehow make up for unreliability > in the IP layer, which it occasionally might be able to do with some effort > (e.g., via DNS-based load balancers that take end-to-end IP reachability > information as input), but it usually doesn't because that's not the purpose > of DNS. And I agree that some applications (and some users) sometimes need > to deal with IP addresses directly, and probably still will need to for a > long time, maybe forever. You seem to be assuming that my proposal was to > disallow such "visibility into the network" entirely, but that wasn't my > intent at all. I just would like it to become no longer _mandatory_ for > every application to know about the structure IP addresses in order to > accomplish anything. > > To be specific, there are (at least) three positions we might be in: > > 1. ALL applications MUST know about IP addresses, in each IP address format > that exists, in order to operate at all. This is the current state of the > world for applications that use the sockets API, because apps have to call > gethostbyname etc. and copy the resulting IP address(es) into sockaddr_in or > sockaddr_in6 structs to pass to connect() et al. Even though the sockets > API is "generic" in that it supports multiple address families, its design > forces the application to have code specific to each family in order to > support that family at all, which is the key problem. > > 2. ALL applications MUST use only DNS names for all operations, and never > provide or see IP addresses for any reason. This seems to be what you're > assuming I'm suggesting (i.e., where you say "...by trying to get apps and > other things to use DNS names >>exclusively<<"). That's a world we might > hold up as an ideal to strive for eventually, but it's indeed not realistic > in the short term, and it's not what I'm pushing for. Besides, there may be > many different naming or host identity schemes we might eventually want to > support besides DNS names - e.g., UIA personal names, HIP cryptographic host > identities, ... > > 3. Applications MAY be aware of IP addresses if they need to be for > whatever reason, but aren't ALWAYS forced to have hard-coded dependencies on > the existence and structure of IP addresses by the API's design. > Applications see IP addresses as variable-length string blobs of some kind > - e.g., along the lines Florian Weimer suggested in another message. > Applications can parse/interpret or create these blobs if they want/need > to, but don't necessarily have to if they're just passing the blob through > from the GUI or URL parser to the OS's protocol stack. This is the position > I think we need to be pushing for. > > In short, I do
The Great Naming Debate (was Re: The internet architecture)
So, after being distracted by OSDI last week, I'm now trying to catch up on the raging debates on TAE that are already exceeding all the wildest dreams I had before setting up the list... :) On the issue of weaning applications (and potentially transports) away from IP addresses in favor of names of some kind, I feel that a lot of the disagreement results from a misunderstanding of exactly what I (and perhaps others who have made similar proposals) was proposing... On Dec 4, 2008, at 10:29 PM, Keith Moore wrote: Hallam-Baker, Phillip wrote: I am trying to parse this claim. Are you saying that the DNS is fragile and raw IP relatively robust? DNS is layered on top of IP. So for a large class of IP failures, DNS won't work either. And if IP routing fails, DNS is likely to be irrelevant because the application using DNS won't work anyway. And in practice, DNS is quite likely to fail due to configuration errors, inadequate provisioning, outdated cache entries due to unanticipated changes, brain-damaged DNS caches built into NATs, failure of registries to transfer a DNS name in a timely fashion, etc. So it's not a question of whether DNS is less reliable than IP (it is), or even whether the reliability of DNS + IP is less than that of IP alone (it is). It's a question of whether increasing reliance on DNS by trying to get apps and other things to use DNS names exclusively, makes those apps and other things less reliable. And I'd argue that it does, except perhaps in a world where renumbering happened frequently, at irregular intervals, and without notice. And I don't think that's a realistic scenario. I entirely agree in principle with your concerns about reliability: if everything has to work correctly in two layers (DNS and IP), then that's strictly less likely to happen than hoping everything will work correctly in only one layer (just IP) - unless DNS can somehow make up for unreliability in the IP layer, which it occasionally might be able to do with some effort (e.g., via DNS-based load balancers that take end-to-end IP reachability information as input), but it usually doesn't because that's not the purpose of DNS. And I agree that some applications (and some users) sometimes need to deal with IP addresses directly, and probably still will need to for a long time, maybe forever. You seem to be assuming that my proposal was to disallow such "visibility into the network" entirely, but that wasn't my intent at all. I just would like it to become no longer _mandatory_ for every application to know about the structure IP addresses in order to accomplish anything. To be specific, there are (at least) three positions we might be in: 1. ALL applications MUST know about IP addresses, in each IP address format that exists, in order to operate at all. This is the current state of the world for applications that use the sockets API, because apps have to call gethostbyname etc. and copy the resulting IP address(es) into sockaddr_in or sockaddr_in6 structs to pass to connect() et al. Even though the sockets API is "generic" in that it supports multiple address families, its design forces the application to have code specific to each family in order to support that family at all, which is the key problem. 2. ALL applications MUST use only DNS names for all operations, and never provide or see IP addresses for any reason. This seems to be what you're assuming I'm suggesting (i.e., where you say "...by trying to get apps and other things to use DNS names >>exclusively<<"). That's a world we might hold up as an ideal to strive for eventually, but it's indeed not realistic in the short term, and it's not what I'm pushing for. Besides, there may be many different naming or host identity schemes we might eventually want to support besides DNS names - e.g., UIA personal names, HIP cryptographic host identities, ... 3. Applications MAY be aware of IP addresses if they need to be for whatever reason, but aren't ALWAYS forced to have hard-coded dependencies on the existence and structure of IP addresses by the API's design. Applications see IP addresses as variable-length string blobs of some kind - e.g., along the lines Florian Weimer suggested in another message. Applications can parse/interpret or create these blobs if they want/need to, but don't necessarily have to if they're just passing the blob through from the GUI or URL parser to the OS's protocol stack. This is the position I think we need to be pushing for. In short, I don't think either the current fascist extreme of an "IP- address-only API" or the opposite fascist extreme of a "DNS-name-only protocol stack" is very appealing; we need an environment in which different kinds of names/addresses/identities can coexist. You'll still be able to enter an IPv4 or IPv6 address instead of a host name when you need to, and applicat
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Cullen Jennings writes: > On Dec 12, 2008, at 1:07 PM, Russ Housley wrote: > >> This was the consensus of the IPR WG and the IETF, > > I doubt the IPR WG really fully thought about this or understood > it. If someone who was deeply involved can provide definitive evidence > of this one way or the other that would be great. I am pretty sure > this was not widely understood when it was IETF LC and I very > confident it was not understood by the IESG when when they approved > it. I agree. I don't recall discussions that the intention was that the documents would require IETF participants to contact earlier IETF contributors about transferring rights to the Trust. I believe the intention was to maintain status quo in this area, i.e., to allow IETF participants to freely re-use IETF documents within the IETF standards process. Given the complexity of the documents, I'm not surprised there are unforeseen consequences like this. Unfortunately, the problems I brought up with the old copyright policy did not lead to discussions of how to reduce complexity. Instead, more complexity was added to work around identified problems. /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
"AJ Jaghori" writes: > Modifying an author's original work without specified permission; > regardless of new findings, constitutes a copyright infringement. Sure, but the old RFC copyright license (e.g., RFC 2026 and RFC 3978) gave IETF participants the necessary rights to allow modifications of earlier IETF work within the IETF standard process. The new one doesn't, and the consequences of that situation is what's discussed. /Simon > > > > On 12/13/08, Christian Huitema wrote: >>> You can improve any technology you want, modulo IPR -- that's not the >>> point here. The problem is taking existing copyrighted text and using >>> it as a base for describing your technology. >> >> That's indeed the problem we stumbled upon years ago. Suppose that a >> contributor has written a complete description of technology X, getting it >> published as a 100 pages RFC. A remarkable feat, and a great contribution to >> the community. A few years letter, the working group realizes that they like >> the technology, but would like to change a couple options. That normally >> translates into changing a paragraph or two, resulting in a new RFC, more >> than 90% identical to the previous one. >> >> Suppose now that for whatever reasons, the original author disagrees with >> the changes, or with the new management of the working group, or with the >> new editor. People are human, these things do happen. IANAL, but my >> understanding at the time was that the original copyright still applied to >> the original text, and that the working group would be left with only bad >> options. They could issue a delta RFC that only contained the modifications, >> but that is somewhat confusing for the readers. Or they could undertake a >> complete rewriting of the standard, but that takes a long time and is also >> prone to errors and confusion. >> >> This is very much why we got the statement on copyrights in RFC 1602, in >> 1996. You will notice that copyrights were only mentioned as something we >> might need to worry about later in the appendix of the previous rules, RFC >> 1310 published in 1992. >> >> -- Christian Huitema >> >> >> ___ >> 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
