Re: RFC5378 alternate procedure (was: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary)
Material comments: - Section 3: RFC 5378 expected the date on which 5378 was effective to be set by the Trust (section 2.1), and explicitly did not want to cast into RFC stone the procedure by which the changeover date was determined. - I disagree with the decision to allow *all* of a submission, including new text, to be 3978-boilerplated. As I've said before, my preferred resolution mechanism is to have a mechanism available (probably front-page disclaimer + details in the Contributors section) for listing pre-5378 sources from which material was copied without 5378 permission being granted by the authors. I believe the continued production of material that is licensed under 3978 only will be long-term harmful to the state of the IETF's IPR confusion. Harald John C Klensin wrote: 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC5378 alternate procedure
John C Klensin john-i...@jck.com writes: 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. Thanks for trying to do something about this problem. I've read the -01 document. It describes a solution that would be very far from a good copyright situation -- even further away than RFC 5378 alone, given that RFC 3978 is seriously flawed in some ways. However, I think your draft is likely to be one of few approaches that can gain consensus quickly enough to be an effective solution to the problem you describe. It could be a stop-gap measure for the next year or so, until better copyright policies can be developed. There is one detail I disagree with rather strongly. Section 7 suggests that the Trustees should prepare a replacement for BCP 78. First, I don't think the Trustees have the necessary competences or resources to take on that huge effort. Further, there is a conflict of interest here: any policies written by the Trustees is likely to just give more rights to the IETF Trust That is the problem that caused this situation to begin with. I don't believe the output would be representative of the needs of the wider IETF community. Instead, I suggest there should be a wider IETF effort to document the copyright policy that will serve the IETF better... ...and hopefully such an effort can review some of the bigger pictures that were declared out of scope in the IPR WG. One consideration would then be: * Whether the two-phase construct with an IETF Trust is a good idea. One alternative is to require contributors to release their work under a liberal license that allows everyone to copy and modify it. This would avoid the liability issues that are inherent in the IETF Trust construct. This would save money for the IETF. The license would be significantly less complex. I agree there are some situations were contributors doesn't find this model acceptable. Just like there are exceptions in the current license, there could be a exception in the new license to allow exceptions for non-modifiable content. Compare how the GNU FDL license restricts certain parts of a manual to be modified freely. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The Great Naming Debate (was Re: The internet architecture)
Two points 1) Let us bury the idea that more parts reduces reliability. If anyone thinks that they do not understand the function of TCP and should go and read some basic networking architecture texts. TCP + IP is more reliable than IP. Ergo it is entirely possible to onfigure a service such that DNS + TCP + IP is more reliable than TCP + IP. It is also possible to design systems such that more layers create less reliability. 2) From an application point of view example.com and 10.1.2.3 may both be regarded as names. They are both rendered as an ascii/unicode string. They both require translation into IP format. 10.1.2.3 is simply a string litteral that may be used in place of a DNS name. In neither case should the application require knowledge of the IP address itself. In fact you don't want that as at some point in the distant future, 10.1.2.3 is actually going to map to an IPv6 address, not an IPv4 address. From: ietf-boun...@ietf.org on behalf of Bryan Ford Sent: Sun 12/14/2008 2:51 PM To: Keith Moore Cc: t...@ietf.org; ietf@ietf.org Subject: 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
Gen-ART Last Call review of draft-ietf-ospf-manet-mdr-03.txt
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-manet-mdr-03.txt Reviewer: Spencer Dawkins Review Date: 2008-12-12 IETF LC End Date: 2008-12-24 IESG Telechat date: (not known) Summary: This draft is on the right track for publication as Experimental. I have a small number of questions, listed below. Comments: 2.6. Hello Protocol Differential Hellos are sent every HelloInterval seconds, except when full Hellos are sent, which happens once every 2HopRefresh Hellos. Spencer (clarity): Is 2HopRefresh a counter? As I continue reading, it seems to be treated as a counter, but that wasn't clear to me at this point in the document (I think I caught up in Section 4.1, but that's later than I'd hoped) The default value of 2HopRefresh is 1, i.e., the default is to send only full Hellos. The default value for HelloInterval is 2 seconds. Differential Hellos are used to reduce overhead and to allow Hellos to be sent more frequently, for faster reaction to topology changes. 3.2. New Configurable Interface Parameters All possible configurations of the new interface parameters are functional, except that if AdjConnectivity is 0 (full-topology adjacencies), then LSAFullness must be 1, 2, or 4 (see Section 9.3). Differential Hellos should be used to reduce the size of Hello packets when the average number of neighbors is large. Differential Spencer (clarity): does large have any relationship with 160 or 200 nodes mentioned in the next paragraph? Hellos are obtained by setting the parameter 2HopRefresh to an integer greater than 1, with the recommended value being 3. Good performance in simulated mobile networks with up to 160 nodes has been obtained using the default configuration with differential Hellos. Good performance in simulated mobile networks with up to 200 nodes has been obtained using the same configuration except with minimal LSAs (LSAFullness = 0). Simulation results are presented in Appendix E. MDRConstraint A parameter of the MDR selection algorithm, which affects the number of MDRs selected. The default value of 3 results in nearly the minimum number of MDRs. The optional value 2 results in a larger number of MDRs. Spencer(clarity): are 3 and 2 the only possible values for this parameter? If so, that's fine, but the chosen values made me wonder about other possible values... 12. IANA Considerations This document defines three new LLS TLV types to be allocated by IANA: MDR-Hello TLV, MDR-Metric TLV, and MDR-DD TLV. Spencer (clarity): it would be good to point to the definitions in this section. D. Non-Ackable LSAs for Periodic Flooding In a highly mobile network, it is possible that a router almost always originates a new router-LSA every MinLSInterval seconds. In this case, it should not be necessary to send Acks for such an LSA, or to retransmit such an LSA as a unicast, or to describe such an LSA in a DD packet. In this case, the originator of an LSA MAY indicate that the router-LSA is non-ackable by setting a bit (to be specified) in the options field of the LSA. For example, a router Spencer: to be specified? Is this the L bit described in A.1? can originate non-ackable LSAs if it determines (e.g., based on an exponential moving average) that a new LSA is originated every MinLSInterval seconds at least 90 percent of the time. (Simulations can be used to determine the best threshold.) ___ 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)
(in the interest of efficiency, I'm going to respond to Harald's and Simon's comments in a single note and pick up one of Hector's remarks in the process) Harald, --On Tuesday, 16 December, 2008 09:53 +0100 Harald Alvestrand har...@alvestrand.no wrote: Material comments: - Section 3: RFC 5378 expected the date on which 5378 was effective to be set by the Trust (section 2.1), and explicitly did not want to cast into RFC stone the procedure by which the changeover date was determined. I understand that. I even believe that the WG decision in that regard, reflected in 5378, was correct in that regard. But we have ended up in a situation in which reasonable people, apparently even practicing attorney-type reasonable people, disagree on the actual effective changeover date and its validity. Except as an example of we don't do this at all well (see below), why that happened is not particularly interesting compared to the importance of properly identifying and solving, or at least working around, the problem. - I disagree with the decision to allow *all* of a submission, including new text, to be 3978-boilerplated. As I've said before, my preferred resolution mechanism is to have a mechanism available (probably front-page disclaimer + details in the Contributors section) for listing pre-5378 sources from which material was copied without 5378 permission being granted by the authors. I believe the continued production of material that is licensed under 3978 only will be long-term harmful to the state of the IETF's IPR confusion. I tried to say this in the document, but obviously not clearly enough. I believe that the right long-term strategy is some sort of hybrid in which earlier text is somehow grandfathered and newer text falls under the newer rules. That is desirable not only for the reason you cite but because, as Simon points out, 3978 has its own set of problems that we should not perpetuate any longer or more than necessary. _However_ there are two problems with a hybrid strategy. The first is that I see almost no chance that we could develop that necessary model, plan, and documentation quickly and get it right (see below). I believe that, if 5378 is taken seriously and is the only permitted posting mode after today, that a number of document and WG efforts are simply going to come to a halt until we get a workaround in place. The just use 3978 until we get this sorted out model of the I-D is a proposal for that (I hope temporary) workaround; it is not a suggestion for a permanent solution. The second is an issue on which I think we need advice from the Trustees and from Counsel and then time to consider and discuss that advice. To a first approximation, the IPR in a document completely created under 5378 rules is extremely easy to understand and administer: the Trust owns the thing and all rights to use it, even for IETF development purposes, derive from licenses granted by the Trust. Similarly, and again to a first approximation, the IPR in the document completely created under 3978 or its predecessors is easy to understand and administer: the IETF can use the document any way it needs/wants to, anyone can copy, distribute, etc., and anyone with another use must seek out the authors for permission. A document that contains both 3978 (or earlier) material and 5378 material is a much more complex proposition. Obviously, the Trust can't grant rights it doesn't have. Probably a grant from the Trust that says you can do X with any part of the document we control, but for anything else you have to have to contact the authors, and we can't tell you which is which is the worst of both worlds... one in which anyone who is being conservative will feel a need to obtain both a license from the Trust _and_ licenses from the authors/ Contributors. Does that mean that, to do a hybrid document, we will have to label each paragraph with its authorship/ 5378 status? I don't know, and that is where consultation with Counsel is needed. One we get those answers, we can start figuring out the tradeoffs and what we _really_ want.But I am certain we won't be able to figure that out and get it right this week, or even this year. Simon, --On Tuesday, 16 December, 2008 15:03 +0100 Simon Josefsson si...@josefsson.org wrote: ... Thanks for trying to do something about this problem. I've read the -01 document. It describes a solution that would be very far from a good copyright situation -- even further away than RFC 5378 alone, given that RFC 3978 is seriously flawed in some ways. However, I think your draft is likely to be one of few approaches that can gain consensus quickly enough to be an effective solution to the problem you describe. It could be a stop-gap measure for the next year or so, until better copyright policies can be developed. That is really all I intend -- something that can get us out of this hole, that could be adopted and implemented
Re: RFC5378 alternate procedure (was: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary)
Cullen Jennings flu...@cisco.com writes: 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. Question. It is my understanding/assumption that the ONLY parties that one must clearance from are the actual listed authors of the document. Specifically, one does NOT need to go back to everyone who might have contributed text. That, at least, is how we seem to have been operating for a long time, i.e, it is only the listed authors that matter. Having said that, things might be murkier than that if one looks at an acknowledgment section to find everyone who might have contributed significant text. I.e., when incorporating comments from individuals in WGs, those contributions are covered by the NOTE WELL. Does the NOTE WELL also need to be extended to cover the expanded rights case? Please say no! Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC5378 alternate procedure
Thomas Narten nar...@us.ibm.com writes: Cullen Jennings flu...@cisco.com writes: 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. Question. It is my understanding/assumption that the ONLY parties that one must clearance from are the actual listed authors of the document. Specifically, one does NOT need to go back to everyone who might have contributed text. That, at least, is how we seem to have been operating for a long time, i.e, it is only the listed authors that matter. I don't believe that is correct in this context -- I believe what matters here is getting the necessary copyright from each respective copyright holder (for work large enough to be copyrightable). The IETF policies has been (and remain) that the copyright remains with the contributor (or possibly his/her employer for work-for-profit contributions). Since old contributions were only given to the IETF under the RFC 3978 (or earlier) license, they need to grant the rights in RFC 5378 too, before it can be used under the RFC 5378 rules. Re-reading the initial answer to Sam's question, it uses the word contributor which is defined in BCP 78, and is not the same as author. That is consistent with my view, however it would be useful to get more thoughts on what the answer is here. Btw, the FSF uses a limit of ten lines of text/code as a rough limit for when a copyright assignment is necessary. The FSF is probably conservative here though. I suppose a similar limit is applicable when you need to contact the original contributor. Having said that, things might be murkier than that if one looks at an acknowledgment section to find everyone who might have contributed significant text. Indeed. I.e., when incorporating comments from individuals in WGs, those contributions are covered by the NOTE WELL. Does the NOTE WELL also need to be extended to cover the expanded rights case? Please say no! The NOTE WELL refers to BCP 78 so it is has already been extended to cover the new expanded rights, hasn't it? /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [tae] The Great Naming Debate (was Re: The internet architecture)
Hallam-Baker, Phillip wrote: So to be strictly accurate here, applications deal in names, some of which are DNS names and some of which are IP address litterals. But an 'end user' application only deals in names. how many people are pure end users who never need their tools to be able to deal with IP address literals? nobody that I know of. even naive users who don't understand what IP addresses do, need for their apps to be able to deal with them for the cases where things break. for instance, when the external network connection goes down and they still want to be able to talk to their printers. [*] actually the vast majority of users that I know of do occasionally deal with IP addresses directly. and many of these guys aren't computer scientists or techies of any sort. again, this is not only hopelessly naive, it's harmful. you're trying to build a system that's even more broken than what we have now. we're a very long way from knowing how to build a naming system that works so reliably and transparently that we can completely hide IP addresses from users. Keith [*] and yeah, I know about LLMNR and even use it occasionally, but it also breaks when you take your laptop on the road and still want to be able to print to the printer at home. ___ 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: 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. Indeed. But more importantly, this sub-thread naturally and inevitably reduces down to an infinite, entirely unproductive finger-pointing game. We have a reality that the new IPR rules are fundamentally problematic. Prior to their imposition, we had a functioning system. Now we don't. And the only thing that changed was imposition of the new rules. Nothing else happened. The proposals are mostly about adding another layer of 'fix' to what was supposed, itself, to be an incremental fix. The odds that we will get that additional layer wrong are demonstrably high. We should, instead, re-invoke the previous rules, until we figure out how to make the correct changes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC5378 alternate procedure
Simon == Simon Josefsson si...@josefsson.org writes: Question. It is my understanding/assumption that the ONLY parties that one must clearance from are the actual listed authors of the document. Specifically, one does NOT need to go back to everyone who might have contributed text. That, at least, is how we seem to have been operating for a long time, i.e, it is only the listed authors that matter. Simon I don't believe that is correct in this context -- I Simon believe what matters here is getting the necessary Simon copyright from each respective copyright holder (for work Simon large enough to be copyrightable). The IETF policies has Simon been (and remain) that the copyright remains with the Simon contributor (or possibly his/her I agree completely. I'll note that it may well be reasonable to assume that small text is fair use. ___ 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
Dave, --On Tuesday, 16 December, 2008 10:26 -0800 Dave CROCKER d...@dcrocker.net wrote: Indeed. But more importantly, this sub-thread naturally and inevitably reduces down to an infinite, entirely unproductive finger-pointing game. For various reasons, I don't believe that game is infinite. I believe that we all had the opportunity to identify these problems during Last Call or earlier and that no one did a careful enough review. That means that the finger points to either everyone participating in the IETF or to the fundamental process we use to review and approve this type of documents. Neither is infinite, but it makes the exercise even more non-productive. We have a reality that the new IPR rules are fundamentally problematic. Prior to their imposition, we had a functioning system. Now we don't. And the only thing that changed was imposition of the new rules. Nothing else happened. The proposals are mostly about adding another layer of 'fix' to what was supposed, itself, to be an incremental fix. The odds that we will get that additional layer wrong are demonstrably high. And that is precisely why my I-D turns things into a choice between new rules and old rules, based only on the conclusion of the submitter about what is important... and why it does not attempt to fix 5378. I agree with you about the odds of getting an additional layer right, especially so if we try to do it quickly. We should, instead, re-invoke the previous rules, until we figure out how to make the correct changes. Yes, just suspend 5378 until we get this sorted out and then, if necessary, repeal it and start over did occur to me. I tried to suggest last week that the IAOC and Trustees figure out a way to do just that, if necessary generating a pro-forma appeal of something that would permit the IESG to take an equivalent action. If I correctly understand the responses we received, that wasn't believed to be possible. The Trustees have advice of Counsel (who is also a co-author of 5378) and I don't in that matter, so, if they concluded that they couldn't figure out a way to defer 5378 and reinvoke the previous rules, I think we need to accept that and move on. Of course, we could generate an I-D whose only substantive text was either move 5378 to historic and un-obsolete 3978 and 4749 or suspend application of 5378 until some specified condition happens. I know how to write the first. I don't know how to write the second, but maybe someone else does. I took the path that my I-D specifies because I concluded that we have gotten into a place in which re-invoking the old rules is not possible. With the usual IANAL disclaimers, it appears to me that we are in the following situation: * Documents have been posted with RFC 5378 language. * At least some of the Trustees believe, presumably on advice of Counsel, that RFC 5378 has been in effect since November 10, that everything done in the IETF since November 10 is covered by it, including everything that happened during IETF 73, and that 3978 became obsolete and of no effect on that date. It appears that all RFCs posted after that date carry the 5378 language. While some of us have a bit of trouble with the logic on which that belief is based, we know that legal logic is sometimes different from normal logic and assume that any controversy about 5378 effectiveness would not be resolved until settled by a court. I can't speak for others, but I don't want to go near that solution if it can be avoided. * Ignoring all of the non-IETF uses for the moment, RFC 5378 is not a linear descendant of 3978 and its predecessors, but a change in direction from authors grant rights to the IETF and its participants to authors grant rights to the IETF Trust, which then grants rights back to IETF participants so we can do work. If we suspend or repeal 5378 to re-invoke the previous rules, it appears to me that any documents covered by the 5378 rules fall into a strange never-never land in which the IETF may have _no_ rights to them at all. Remembering that set of documents contains anything from several RFCs and I-Ds to all of IETF history since before IETF 73, that is an unattractive situation, to put it mildly. * One could argue that everything published or contributed between November 10 and now is still covered by the (old) Note Well and hence that the old rules are still in effect in parallel to the rules of 5378, i.e., that Contributors are making both the old grant direct to IETF participants and the new grant to the IETF Trust. That position would be a little inconsistent with the assertion that 3978
RE: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hesham Soliman Sent: Monday, December 01, 2008 2:33 AM To: Colin Perkins Cc: TSV Dir; ietf@ietf.org; m...@ietf.org Subject: Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt Thanks Colin, I agree with your rationale but I wonder if we need to support every broken device out there. In any case, if we have to, I prefer to require encryption than to add the XORED address option. I'd like to hear what people in MEXT think about this, comments from MEXT? (catching up on email after a long vacation; sorry for the delay.) FYI, Teredo also found NATs that meddled with IP addresses on 32 bit boundaries. From RFC4380, Other investigation in the behavior of NAT also outlined the probabilistic rewrite behavior. Some brands of NAT will examine all packets for embedded addresses, IP addresses, and port numbers present in application payloads. They will systematically replace 32-bit values that match a local address by the corresponding mapped address. The Teredo specification includes an obfuscation procedure in order to avoid this behavior. -d Hesham On 1/12/08 9:13 PM, Colin Perkins c...@csperkins.org wrote: On 1 Dec 2008, at 09:00, Hesham Soliman wrote: = Well, I'm not sure how a NAT can do that. You mean the NAT will parse the binding update message deep inside the IPv6 extension header in the inner IP packet? This is where the original address is preserved. To do that, a NAT would have to understand the various MIPv6 options, and if it did, it would know not to do that :) The inner header is IPv6, so a NAT should not touch that. My understanding from the STUN work is that NATs have been observed which rewrite any sequence of four aligned bytes matching the source IP address, irrespective of its location within the packet (section 15.2 of RFC 5389). = Sounds freightning! May be we need to mandate encryption and hope that no 4-byte sequence matched the IP address? What do they do with encrypted packets? How do they know they're encrypted? One would assume these broken devices will potentially corrupt encrypted packets, the same as they will potentially corrupt any other packet. Hiding the source address when it appears in the payload (either by encryption, or using some trivial obfuscation as does STUN) simply reduces the probability of such corruption so it's no longer 100% guaranteed that the payload will be mangled. ___ 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
John == John C Klensin john-i...@jck.com writes: We have a reality that the new IPR rules are fundamentally problematic. Prior to their imposition, we had a functioning system. Now we don't. And the only thing that changed was imposition of the new rules. Nothing else happened. The proposals are mostly about adding another layer of 'fix' to what was supposed, itself, to be an incremental fix. The odds that we will get that additional layer wrong are demonstrably high. John And that is precisely why my I-D turns things into a choice John between new rules and old rules, based only on the John conclusion of the submitter about what is important... and John why it does not attempt to fix 5378. I agree with you John about the odds of getting an additional layer right, John especially so if we try to do it quickly. For what it is worth, I as an individual support the new rules, and believe Russ gave me a fine answer. I would not support turning this into a choice. ___ 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
At 13:41 16-12-2008, Sam Hartman wrote: For what it is worth, I as an individual support the new rules, and believe Russ gave me a fine answer. You asked a good question. I would not support turning this into a choice. According to a message [1] posted by the IETF Chair, the updated boilerplate is required as from December 16. There was a Last Call on December 16 for draft-ietf-sieve-managesieve. There is a sub-section in that I-D that is similar to text found in RFCs on the Standard Track. Previously, reuse of text as part of the Standard Process wasn't an issue. One could even argue that the reuse of some text falls under the doctrine of fair use. If I were to send comments pointing out that some parts of the document are not in line with what RFC 5378 prescribes, the IESG may have to determine whether BCP 78 and BCP 79 were followed even if the IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights. 1. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05509.html Regards, -sm ___ 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
I have a very different view of this situation, and disagree wstrongly with John's recommended fix (or the equivalent fix of completely rolling back 5378 and 5377.) First and foremost, it should be kept in ming by anyone reading this that the IPR working was convened by the then IETF chair, and continued by succeeding chairs because there were problems that actually needed to be fixed. There are things that the community considered (and presumably still does consider) either necessary or important that are not properly addressed by the earlier documents. This varied between a lack of clarity in some areas, and a lack of ability to perform necessary actions in other areas. The working group was not convened just because we wanted to, or even because we thought we could make things better. If it had not appeared that there were significant problems, I for one would have taken the much easier course and just said leave it alone. And I am quite confident I am not alone. Secondly, giving people a choice of terms is basically going to create confusion. For example, one of the issues raised in the working group was that our previous rights grant appeared not to properly allow folks to modify code. And it required them to include things in used code that made it hard to use that code in various contexts. We want to see implementations. We want to see accurate, interoperable implementations. Using the code and tables from various RFC is somewhere between necessary and and desirable. But, if we assume that the folks who were concerned were right, then if we give everyone a choice, anyone trying to right code using our tables, etc has to figure out what rights they are being granted to use any given RFC or I-D. Yes, there are those who argued that there was no problem. However, the WG concluded that there was at the very least significant confusion, and probably an actual problem. Yes, having to get rights from folks is a pain. But if we are not willing to push to do that, then we might as well consider that the rights granted to the IETF are locked in stone forever, and can never be upgraded, because it will never happen. It should be understood also that some folks actually wanted us to go further than we did in 5377. 5378 and 5377 represent the best compromise we could work out. The community is certainly free to decide that it doesn't want to do that. While some folks who were there say that they feel not enough attention was paid to this issue, it is the case that we did discuss at least some of the impact, and none of what turned out to be needed surprised me. Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-sieve-managesieve (A Protocol for Remotely Managing Sieve Scripts) to Proposed Standard
The IESG has received a request from the Sieve Mail Filtering Language WG (sieve) to consider the following document: - 'A Protocol for Remotely Managing Sieve Scripts ' draft-ietf-sieve-managesieve-05.txt 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 i...@ietf.org mailing lists by 2008-12-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sieve-managesieve-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17794rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
